OpenID only replaces authentication, so yes you would still have to create an account to store user information. Most sites make OpenID an optional auth scheme, with the traditional user/pass being the main one.
But perhaps the question is: How does a client get an account today?
If you run both a provider and a consumer service, you could create the identity during sign-up. You wouldn't have gained a whole lot then, if you only have one application, but if you have a whole suite of sites for clients to log in to, it can still make sense.
Short answer is no. OpenID is a shared authentication scheme - not a single sign on scheme. You could use a SSO scheme instead - There are open standards for that (Although most implementations are in Java space). If you run both the provider and consumer end of OpenID, you could attach some hacks on top of it, but then you really wouldn't have OpenID anymore.
Lots. First of, you have to trust the providers, and OpenID is designed so that the user can pick any provider. Second, OpenID has all the problems that exists with traditional auth schemes (Session hijacking etc.). The only real benefit of OpenID, from a security perspective, is that you don't store the password on each application. So it's mainly a benefit as seen from the users perspective - not from the individual applications. That still doesn't mean that you shouldn't do it - Just don't expect that it somehow heightens your applications security level.