In addition to this, the wiki 'type' value we ask users to set has no impact on these settings and sometimes does not reflect the permissions at all.

So in my mind, there are two possibilities with this, we either set this in the background - automatically based on the user's selected permissions, or we have it 'preset' the permissions and leave it on the same page to allow the user to flick between them to try out different permissions (allowing some customization but suggesting a change in the type automatically if those changes equal or end up similar to other types)

Alternatively, we could scrap the 'type' and allow users to select a permission option that enables all the related extensions for those types - like access from certain emails and whitelisting.

the wiki 'type' value we ask users to set has no impact on these settings and sometimes does not reflect the permissions at all

Actually it does, kinda. On step 3, "Editing restrictions" and "Viewing restrictions" drop-down menus don't appear unless the wiki type is either private or school (although they, for whatever reason, did appear to me once even when wiki type was set to public. JS is weird.).
Furthermore if the chosen wiki type is "school", then the additional option "Users with an email address from" appears in both of the aforementioned drop-down menus. This causes a configuration variable, either $wgViewValidEmail or $wgEditValidEmail to be written to the generated Settings.php file. And as you noted, these two variables do nothing even though they probably should. We should probably look into integrating the PrivateDomains extension here somehow, since AFAIK the underlying idea was always to use PrivateDomains for these not-so-public wikis.

But yeah, +2 to redesigning this beast. It's about time. :)

Mockup for the first page:

• URL: add the prefix before the input if they check the box inline - box will no longer line up with everything else, but the overall line will (apologise if that is current behaviour, I can't remember)
• Access and visibility: recommend replacing the types and visibility and whatnot with just a flat list of possible combinations, or separate dropdowns for each, rather like how this is handled in the mw installer
• General description: you probably want a better example and explanation, but the key here is to give them an idea of what is expected, and explain why they're filling it out, what it will be used for

Also note that the form styles like the buttons and stuff should actually be provided by the skin or mw-ui/oojs; unfortunately none of the skins actually do, and stuff. But the padding would be standard form padding; the blue button would be standard progressive, etc.

Considering we don't have anything providing that anyway, kludging styles in this for more readability is justified.

For page two, make it out like sections for each skin, with a big checkbox by the title of each. Technically the entire thing is a table, as such:

<table>
<tr><td>[checkbox]</td><td>NAME OF SKIN; some info about the skin</td><td>[thumbnail of skin]</td></tr>
<tr><td></td><td colspan=2>Theme selection and stuff using radio boxes; any other random options</td></tr>
...
</table>

Or something. Maybe it doesn't actually need to be a table, but laid out like that, styled like the first page.

I forgot what page three is, but remove any redundancies, clarify any unclear bits, group related bits, etc. Basically like the page 1 changes.

For page 4, either get rid of it, or sum it up in prose with headers, as opposed to using a table. Tables make people's eyes glaze over.