Dynamically create a cmdlets/module in PowerShell - powershell

Question

This is what I want to achieve and I can't find anything about this.
I want to create a remote module proxy, for a module that is available on a remote server.
I know how to work with remoting but I want something that creates cleaner script files.
To give an example. If I want to execute MyCmdlet from module MyModule on a remote computer I would do this
$block={
# Invoke the cmdlet from a module named MyCmdlet
MyCmdlet -Parameter1 -Parameter2
}
Invoke-Command -ComputerName "" -ScriptBlock $block
But I would like to land into something like this
Import-Module MyModuleRemote
MyCmdlet -ComputerName "" -Parameter1 -Parameter2
Please noticed that MyModule is not installed on my client machine.
I could re-write the module with Invoke-Command wrapper for each cmdlet but that is not the purpose. What I would like to do is remot-ify the MyModule by creating an proxy equal proxy per cmdlet and parameter. Even the Get-Help should work at least for the parameter composition.
I have a couple of ideas but I'm not sure if it is even possible.
Create a powershell module e.g. PSRemotify that will probe the module on the remote server and generate the code.
If I chose to write files to the file system then this should be possible, if I could do reflection on the cmdlets.
If I don't want to save files then I need to do everything in memory. Can I write a cmdlet's body in memory? Can I generate a string and import its embedded cmdlet?
Create a script that does 1.2.
My preference would be option 1.2. Very clean and without leaving any traces on the file system.
Any ideas? Has anybody tried something like already?
Conclusion after my investigation and answer from #Persistent13:
PowerShell offer this feature out of the box. it is known as IMPLICIT REMOTING. Before #Persistent13's answer I took the wrong part because I think it is interesting to share my experience, I've blogged about it.
import and use module from a remote server

Answer 1

It sounds like what your looking for is implicit remoting and is fairly simple to set up.
Please note I've taken the instructions for this from here.
To create an implicit session you would:
PS C:\> $foo = New-PSSession -ComputerName DC1
PS C:\> Import-Module -PSSession $foo -Name ActiveDirectory
PS C:\> Get-ADUser
The above would open a PowerShell session on the computer DC1, import the ActiveDirectory module on the remote computer, and the command is run against the remote computer while it appears to be executed locally.
It is also possible the prefix the implicitly imported modules in case a local module would conflict with the remote one.
PS C:\> $foo = New-PSSession -ComputerName DC1
PS C:\> Import-Module -PSSession $foo -Name ActiveDirectory -Prefix DC1
PS C:\> Get-DC1ADUser
The advantage of this is there is no need to remot-ify your module and so long as it is present on the remote computer and PowerShell remoting is allowed.
However one caveat of this method is that the type of the object returned will change.
Deserialized.Microsoft.ActiveDirectory.Management.ADUser when implicit remoting is used.
Microsoft.ActiveDirectory.Management.ADUser when run locally.

Answer 2

When I raised the question back then, I didn't know the concept of implicit remoting.
In practice you import a module using Import-Module but you also specify a session to a remote server with the -Session parameter.
For example to import Microsoft.PowerShell.Management from server $target="SERVER" execute this
$session=New-PSSession -ComputerName $target
Import-Module Microsoft.PowerShell.Management -Session $session
With this a proxy module is generated in the current session that offers the same cmdlets as the one specified. The proxy cmdlets automatically push the parameters to the remote session $session and capture its output. With Microsoft.PowerShell.Management implicitly imported from SERVER the Get-Service returns the services from SERVER.
You can really see the implementation of the proxy cmdlets by executing
$module=Get-Module Microsoft.PowerShell.Management
$module.Definition
It's at least interesting.