To me it sounds like this might be something better suited to a single site install vs. multi site. But it really depends on how customized things need to be for a single user.

NOTE: this answer will not include information about server setup, etc.

First off, I would define WP_HOME and WP_SITEURL in wp-config.php and make them unchanging. You can probably set these dynamically, but the results needs to be that they point to the main, root domain. My local WP install is wordpress.dev, so I'll use that throughout this answer.

Example:

<?php
// in wp-config.php
define('WP_HOME', 'http://wordpress.dev');
define('WP_SITEURL', WP_HOME . '/wp'); // wp in sub directory
define('WP_CONTENT_DIR', dirname(__FILE__) . '/content');
define('WP_CONTENT_URL', '//' . $_SERVER['HTTP_HOST'] . '/content'); // protocol relative content URL

Next we need to set the user based on the current subdomain. This should be relatively easy: parse the HTTP host, look for a user by that username, set that user as the user for later. I'd suggest wrapping everything in a class (a singleton here).

<?php
class WPSE66456
{
    // container for an instance of this class
    private static $ins;

    // The current user, based on subdomain.
    private $user = null;

    /***** Singleton Pattern *****/

    public static function init()
    {
        add_action('plugins_loaded', array(__CLASS__, 'instance'), 0);
    }

    public static function instance()
    {
        is_null(self::$ins) && self::$ins = new self;
        return self::$ins;
    }

    /**
     * Constructor.  Actions really get added here.
     *
     */
    protected function __construct()
    {
        // empty for now...
    }
} // end class

Then we need to write something to parse $_SERVER['HTTP_HOST'] and see if we get a valid username from it.

<?php
class WPSE66456
{
    // snip snip

    protected function __construct()
    {
        $this->set_current_user($_SERVER['HTTP_HOST']);
    }

    protected function set_current_user($host)
    {
        if(!is_null($this->user))
            return;

        list($user, $host) = explode('.', $host, 2);

        // gets tricky here.  Where is the real site? Is it at the root domain?
        // For the purposes of this tutorial, let's assume that we're using a
        // nacked root domain for the main, no user site.

        // Make sure the $host is still a valid domain, if not we're on the root
        if(strpos($host, '.') === false)
        {
            $this->user = false;
        }
        else
        {
            if($u = get_user_by('slug', $user))
            {
                // we have a user!
                $this->user = $u;
            }
            else
            {
                // invalid user name.  Send them back to the root.
                wp_redirect("http://{$host}", 302);
                exit;

                // Or you could die here and show an error...
                // wp_die(__('Invalid User'), __('Invalid User'));
            }
        }
    }
}

Now that you have a username you can do all sorts of things. As an example, let's change the blog tagline to a greeting for that user.

<?php
class WPSE66456
{
    // snip snip

    protected function __construct()
    {
        $this->set_current_user($_SERVER['HTTP_HOST']);
        add_filter('bloginfo', array($this, 'set_tagline'), 10, 2);
    }

    // snip snip

    public function set_tagline($c, $show)
    {
        if('description' != $show || !$this->user)
            return $c;

        return 'Hello, ' . esc_html($this->user->display_name) . '!';
    }
}

Assuming you use the root, naked (no www) url for your install, WordPress will send cookies to all the sudomains. So you, can check to see if a user is viewing their own subdomain and throw them back to the root, otherwise.

<?php
class WPSE66456
{
    // snip snip

    protected function __construct()
    {
        $this->set_current_user($_SERVER['HTTP_HOST']);
        add_filter('bloginfo', array($this, 'set_tagline'), 10, 2);
        add_action('init', array($this, 'check_user'), 1);
    }

    // snip snip

    public function check_user()
    {
        if($this->user === false || current_user_can('manage_options'));
            return; // on the root domain or the user is an admin

        $user = wp_get_current_user();

        if(!$user || $user != $this->user)
        {
            wp_redirect(home_url());
            exit;
        }
    }
}

Finally, the last thing to consider would be that WordPress allows things in user names that won't work with the domain name system. Like user.one is a valid user name. But user.one.yoursite.com is two subdomains deep and not going to work.

So you'll need to hook into pre_user_login and sanitize things.

<?php
class WPSE66456
{
    // snip snip

    protected function __construct()
    {
        $this->set_current_user($_SERVER['HTTP_HOST']);
        add_filter('bloginfo', array($this, 'set_tagline'), 10, 2);
        add_filter('pre_user_login', array($this, 'filter_login'));
        add_action('init', array($this, 'check_user'), 1);
    }

    // snip snip
    
    public function filter_login($login)
    {
        // replace anything that isn't a-z and 0-9 and a dash
        $login = preg_replace('/[^a-z0-9-]/u', '', strtolower($login));

        // domains can't begin with a dash
        $login = preg_replace('/^-/u', '', $login);

        // domains can't end with a dash
        $login = preg_replace('/-$/u', '', $login);

        // probably don't want users registering the `www` user name...
        if('www' == $login)
            $login = 'www2';

        return $login;
    }
}

all of the above as plugin.

There a lot of concerns that aren't addressed in this answer. Does this scale to where you need it to scale? How will having multiple subdomains of very similar content impact search optimization? How much content gets customized? If it's a lot, would multi-site be better suited for this task?