Chris's interpretation to managing *themes* compared to *skinning* is correct, and if nececssary you can do some changes to the core that can reside quite happily, especially if you're using tokens, like the links that are displayed. EG the Tokens like the Links are stored here - in the Admin Folder.
If you are comfortable with coding.. I have no idea if this is possible, you would work on a renamed files - instead of being Links.ascx, copy and rename to LinksNT.ascx or whatever and format it appropriately.. Then you would replace the Links.ascx below to LinksNT.ascx in the skin file.
<%@ Register TagPrefix="dnn" TagName="Links" Src="~/admin/Skins/Links.ascx"%>
Sure this is a modification, but if you keep the same file there - you've got a fallback. Then you can work on your customised one and utilise that.
This does mean more maintenance, particularly with site upgrades, but the interesting thing now is that the modules themselves, being detached in the manner they are, now have their own projects so you can be kept informed on changes to them, and see how they affect you.
And if you're running multi child portals, it could also help you maintain the integrity and have the option of experimenting on a particular module - like the links module without affecting anyone.
So while it's not an answer, it's a work around because Chris is right - the whole dynamics and behaviour of modules is not related to the skinning element, and you can see the even by how the tokens for skinning sites are in a totally different folder and while intergrated, pertain the to the look and feel of the module, whereas the module pertains the functionality.
Why not give that a try and start experimenting - since if I'm right - you're on a mission to create CSS based management - and that's cool - I've just spent too long on it now and it wore me out, so I function on the what DNN has to offer these days and it's great to see others take it a small step closer.
Nina Meiers