Anne's suggestion to look at an authentication plugin is definitely a the first step, as you will eventually need to create an auth plugin to interoperate with your SSO.
I'd like to suggest however you look specifically at either the standard Shibboleth SSO auth plugin, or a customized version of it we use (here).
With regard to question no. 3--you can't disable manual auth because you'll always need the administrative user. You can change the default login page people see by using the $CFG->alternateloginurl (authentication admin). We could set that up to take users to the /auth/shibboleth/index.php--which is Shibboleth protected and will bounce users directly to the SSO login page if not already authenticated. (more about that later).
With regard to question no. 2--besides returning 'true' from user_login() in your auth plugins, a few things, a model for which is found in /auth/shibboleth/index.php.
With regard to question no. 1 (create new user), you won't have to. Moodle will create the user for you after your auth plugin has authenticated the user. If you look at either of the plugins I mention above, they implement the get_user_info() method--which is called from Moodle core routines (create_user_record and update_user_record).
The other significant method the auth plugin has to implement is user_login() method. This method takes two parameters (username, and password)--but of course, in an SSO arrangement, you won't have either of those supplied directly by the user, and really not by the SSO either--at least not directly.
The point to remember with an SSO, is that after authenticating is has to return the user to some endpoint back at the service provider (Moodle), and it's that endpoint that will communicate the authenticated user information to your auth plugin.
For example, the Shibboleth SP (the service provider component on your Moodle host) is instructed to return authenticated users to /auth/shibboleth/index.php--and it's there where it communicates with the SSO (in a manner, via server variables that have been injected into the request by the Shibboleth SP). That index.php page then supplies the username (authenticated) and a dummy password to the auth plugin. The auth plugin then checks that the username (passed in from the server variables matches) matches what is in the server variables--and returns true. At that point Moodle core code creates the user for you with info from the get_user_info call.
So, there's the basic anatomy of the Shibboleth plugin. Whether or not that is useful depends on the SSO you have to use.
Instead of collected authenticated user information from server variables as Shibboleth does, you would do your back-channel communication to the SSO, exchanging a token for the user information.
Question becomes, what is this SSO you're using? Is it a standards based SSO, or something homegrown?
