Adrian, welcome to DNN!
As you suspected, DotNetNuke doesn't inherently have the nesting capability you are looking for. 
Here's my $0.02 -
You can make a skin using your graphics and header/footer, with one content pane - and use it for your "Admin" skin.
This skin will be used for login/out, admin settings, etc. and it would consist of three tables - header, content area and footer.
Build it and test it, get the header and footer working/looking exactly the way you want.
From there, duplicate this 'Admin' skin and change only the content area.

As far as "if anything changes" - don't worry, it will!  But the dotNetNuke core team is good about including backward compatibility.

Option 2 is actually how DNN works.  Functionality is built into modules.
Option 3 means you'd have to re-write default.acpx on every code update - avoid this if possible. 

Does this make sense?

Thanks much for the feedback, it is helpful.

I think the downside of option 2 (using one skin with a single center region, and making each page layout one module) is when it comes time to change the layout of the page. If I make direct use of modules such that each of my current user controls becomes one module, then our html look & feel expert can tweak the layout just by modifying the skin. I think this is great, and I totally dig the way DNN is designed to promote this. If I make each page layout one module, she would have to go edit the module itself to change the layout. This is not horrible, this is what we do currently with plain asp.net 2.0, but she would definitely like being able to stick to just the skin editing.

As far as includes go, I can see the usefulness but it is still pretty similar to the option 1 solution. If I don't use includes, I would just reference my global header control like:
<uc1:globalHeader id="globalHeader" runat="server"/>
in every skin (along with the Page Register directive). It seems to be essentially the same benefits/drawbacks either way.

Another option I was considering is using a masterpage like I do currently and just setting it at runtime (so I don't have to edit default.aspx to specify it). But if memory serves I don't think I have access to this from within a Control, I think only a Page can set it. I'll have to check. In any case, I'm leaning towards the solution of just using one skin per page layout and referencing my header and footer control in all of them. We will just have to be careful when creating a new skin to include them, but this is not too dangerous since we will only have a handful of different page layouts. I guess I could always consider extending our publishing script to do some QA checks and enforce a rule that all skins must have the header/footer references. Or maybe just write a tool that flattens nested skins so I can manage skins in a nested manner but have them look flat for DNN ;)

Thanks,
Adrian