DotNetOpenAuth: Webforms, Getting Started
You don't need to use the project template. You can drop the OpenIDSelector control into any web app and it will Just Work in the minimalist "give me the username" way out of the box. There's no SQL dependencies whatsoever in the DotNetOpenAuth library. Just handle the OpenIdSelector.LoggedIn event and you'll get the username you want.
The project template, bloated as it may seem to you, assumes you actually have user data to store, and that you want to provide a reasonable log in and account management experience. It also works in web farms and cloud hosted environments. If you're starting from scratch this is a great way to get started, although naturally some code that it comes with will apply less than others, which is why you have the source -- so you can change it.
Yes, the project template includes a dependency on a database. It uses Linq-to-Entities so any database with an Entities provider works -- not just SQL Server. And it comes with the schema for that database built in. Just run setup.aspx and it should create the database for you in your local SQLExpress install.
1 - claimed identifier is what you're looking for. the issue is that google and the like use 'directed identity', which means that the claimed identifier will be linked to the realm you come from. net result for you - the same user may come through under multiple different claimed identifiers.
2 and 3 i don't know about - i'm assuming this is some out-of-the-box functionality DNOA does, but i haven't played with it.
4 - not that i've found. dnoa covers all the cases you need to worry about.