You could do this with a customized sunrise.php file. This is essentially how the domain mapping plugin works, however it puts a pretty front end on it. For something custom, you can write some simple PHP to do basically the same thing.
The essence of multisite involves figuring out what site to serve. The Domain mapping plugin does this by creating a wp_domain_mapping table, and storing the information in there. Thus when it gets a request for xxx.com, it looks in that table and sees that that corresponds to blog_id 123.
First, make a WordPress setup, and make it multisite. Doesn't matter where it really lives, because we're going to change all that. For simplicity, I'd put it at blog.stackexchange.com and make it a subdirectory type site (those are easier). The subdirectories created would likely be the slugs. /wordpress, /apple, /whatever.
So yes, to start with, you are indeed making it live at blog.stackexchange.com/wordpress. Consider this your staging environment. When you create each site, you can do stuff to it here until you decide to turn on the mapping.
To do domain mapping yourself, without the plugin, you'd do something like this:
Step one: add define( 'SUNRISE', 'on' ); to the top of your wp-config.php file.
Step two: create a sunrise.php file in the wp-content directory. Put <?php at the top to start with.
Step three: In the sunrise.php file is going to be your logic for determining what site to load.
You're going to base this on the $_SERVER[ 'HTTP_HOST' ] variable. How you do that exactly is easy: however you want to do it. If you want to just write a regex to look for '/blog\.(.*)\.stackexchange\.com/' and then look for that bit in the database, you can do that.
Since you're using the same slug here as the "subdirectory", you don't need a separate table. You can just look in the main wp_blogs table to find the site you need. Something similar to this:
$current_blog = $wpdb->get_var( "SELECT blog_id FROM {$wpdb->blogs} WHERE path = '/wordpress/' LIMIT 1" );
Once you have the $current_blog, then you need the following code:
$current_blog->domain = $_SERVER[ 'HTTP_HOST' ];
$current_blog->path = '/';
$blog_id = $current_blog->blog_id;
$site_id = $current_blog->site_id;
$current_site = $wpdb->get_row( "SELECT * from {$wpdb->site} WHERE id = '{$current_blog->site_id}' LIMIT 0,1" );
$current_site->blog_id = $current_blog->blog_id;
This pre-defines the $current_blog and $current_site global variables instead of letting WordPress' MU functions do it.
This would be enough to get the site up and working (after getting your DNS to point to it and getting the virtual hosting stuff sorted out), however most of the static URLs used in the HTML code would still point to blog.stackexchange.com/wordpress, since that's where the site would really be. Also, the Canonical URL function would probably not like the URL and would redirect you too.
To remedy these problems, you'd also likely want to pre-define several of the URLs associated with the site. Things like WP_SITEURL and WP_HOME. Also, WP_CONTENT_URL, WP_PLUGIN_URL, and WPMU_PLUGIN_URL. That should cover most cases of the URLs being adjusted.
Finally, you'll want to set the 'COOKIE_DOMAIN'. Since you likely want logins to be shared across the whole of the thing, you can set it to stackexchange.com, or even higher if you don't want them to be shared logins.
If you want to talk about integrating the normal stackexchange login system into WordPress, I can answer questions on that too, but it would be a bit more detailed of an answer. :)
Feel free to email me if you want more help with this. Glad to assist: otto at wordpress.org.
