I assume I can use my own masterpage ?

I was under the impression that a skin was applied to a type of a control, within the context of a theme (App_Themes/theme_abc/label1_skin).  Good point about the caching though, I wasnt aware of that.  Would that be an issue for example if you wanted to dynamically change the style of a row within a gridview ?  For example, something like this
http://www.toyotaofkilleen.com/NewInventorySearch.aspx?SeriesCode=TA4&From=Launchpad

Actually, if you look at the source of that page above, they appear to be using a master page (clue is using content placeholders), so maybe not.  That link above is a nice example of using a gridcontrol (or prbably a gridview).

This evening I plan on reviewing the mojoportal source a lot closer, but for now I have some more questions about user logins and user management (which might be answered after i review the source a bit).  After reviewing the 2.0 demo user mangement, i think this very like is going to fit what I need to do with the addition of user verification which I will have to add.  Thats something ill be looking at very shortly so we can discuss ideas on that.  That soulds like a possible addition that would be generic enough to add to the trunk ? 

Also:
-I really like the ability to give someone access to the content editors.  Can I lock this down to only certain areas, admin users and turn it off completely for normal users ?
-for the user, can i make only a selected set of pages require login ?
-for the user management, can i add additional fields for user profile data ?
-regarding the mojoportal source, what is the base/minimum set of subprojects / assemblies that i need If I just want (for now) a site with user login and user management ?
-can I apply the membership schema to an existing database, or is it best to keep it seperate ?

Im sure ill have some more questions soon.

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.
http://www.mojoportal.com/rolesandpermissions.aspx
http://www.mojoportal.com/addingcontent.aspx
http://www.mojoportal.com/managingusers.aspx

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
http://forge.novell.com/mailman/listinfo/mojoportal-svncommits

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