Yes, you can create your own skins which have your own master pages. When I say skin I'm referring to mojoportal skins though the theme files also have that .skin extension, I was calling them skins before 2.0 .NET came out.
The stuff in App_Themes folder is not used except to fool the .NET framework. There is only 1 theme file per skin named theme.skin and it is stored in the skin folder Data/Sites[SiteID]/skins/[skinname] and we use a custom VirtualPathProvider and VirtualFile to make .NET retrieve it from there instead of App_Themes but it still needs a theme.skin file to exist in App_Themes to satify internal .NET checks
If you look in the theme.skin files in the skin folders you will see that most of the .NET server controls are stubbed out there. If you use the theme to just set css classes you can avoid the cache issues whereas if you directly set other properties the cache will get in the way of making some pages use one skin and others use a different skin.
Regular users don't have content edit permissions unless you put them in a role that has edit permissions. It is very easy to give a user edit permission on only a page or section of the site by setting roles that can edit and roles that can create child pages on a page. If a user is in the role with edit permission they can edit that page. If also in the create child page role the user can create more pages beneath the page and edit them but still has no edit permission on other pages outside that sub tree.
A user can also be given edit permission directly on a module instance from module settings (gear icon in module) without having to create roles or give general edit permission to a page.
Please review these docs, they should help you get up to speed on what is possible and I am happy to fill in gaps if you have questions.
If you would like to implement the feature for admin approval of registration and contribute it that would be nice. Please send me an email indicating that you agree that any contributions you make to mojoportal can be included under the mojoportal license, currently Common Public License, but please also agree that we can release it under any OSI approved license so that if we ever decide to change the license we don't have to track you down.
Although the svn instructions currently say use branches/2.1, that branch is not going to have any changes unless we have important bug fixes before we are ready for the next release. for current development use branches/2.1.1 but be aware that it is under heavy development and may not always work perfectly. Best if you subscribe to the svn commit mailing list so you get notified when new commits are made to svn
trunk is the .NET 1.1 framework/mono version, it is only under maintenance until mono better supports 2.0 then it will be tagged and the 2.x version of mojoportal will become trunk
You can only leave out assemblies for data layers you are not using. There is no version with only user management. The content modules are all included though you don't have to use them they are not in separate assemblies. It is possible to implement modules as separate projects/assemblies but the built in ones are not made that way