Using multisite for a ReSTful API and Auth Strategy My Situation

I have a small app with a public interface. I'm interested in making an API for this to be used in a mobile environment and even eventually as a public API. I want to keep it simple with the priority on aspects like security and performance.

My Plan

Why Drupal? Well, I know Drupal and I can envision a setup where I have 2 sites. www.mygui.com (default) and api.mygui.com (API). All database structure is determined by the work done in the default site. Using the Drupal Services Module (and only a few other necessary core modules) on the API site I plan to allow authenticated updates to the database by way of JSON and the drupal_internal_api.

My Problem

I already have a prototype (not in drupal) that uses tokens. I'm new to services and don't really know all its limits and capabilities yet. This looks promising but still in the pipeline: Drupal Services Auth Token Module. I would like advice or resources regarding a good authentication strategy. For example, which is best? Keep the user base the same with assigned "API Uer" roles or have a completely separate user base specifically for the API site? Keeping in mind that an API username is a long term setup where the username/password or token should not change until the API user is ready with a new app release? Can I have a nice GUI for users to manage their API site credentials on the default site?
This can certainly be achieved without any multisite. Meaning you could always house the API on the same site and proxy the path api.mysite.com to mysite.com/api thus allowing it to be invisible to the user. (Make sure your webhost supports mod_proxy or you have some external proxy you can use for this task)

As for the actual authentication, I don't bother with tokens. Use credentials. This way people can get and keep a session (in line with however long you want them to based on session_lifetime in your settings.php) - After an initial call to a log in path, they can then subsequently call the API over and over again by passing the unique session they are assigned.

Go with the single site approach and use web proxy magic to make it look like a different domain. Easy enough.