In order to implement this we need to consider the behavior of the system before a user logs in (when the application starts), when a user completes the log in, and when the user logs out.
We'll need the ability to define a set of modules that are loaded for all users. This would be done using a service, whose implementation could either be local using some config etc., or via a WCF service. This service would return a list of fully qualified
type names and accompanying information for the set of default modules. If we are talking about the Silverlight implementation then this would be used to request the xap files from the server using Prism's existing deferred loading.
When the user logs in, the same service should be queried for the list of modules allowed for the user's role. At this point, the IModuleCatalog can be populated, and loading of modules would work the same way.
For the unloading of modules, I would suggest that modules should be written in such a manner that they are able to remove themselves. I would say an extension to the ModuleBase class including an event to subscribe to for concrete modules to unload themselves.
The module management infrastructure will need modifying, in order to update dependencies and unload other modules if they are dependent on any other module being unloaded.
The other options for unloading of modules are loading the module in another app domain (not really feasible) or recycling the AppDomain. The latter option is easy to do if using Silverlight in Browser.
Just for your information regarding the progress of Calcium development. I have recently completed the porting of the core library for WP7. While my time right now is quite taken up writing a book on WP7, I am very eager to move forward with Calcium.