Only allow Stored Procedure access to users in SQLServer 2005?

You're right about the schema/user/role model being somewhat confusing.  Let me suggest an easy implmentation that should work unless you have unusual needs:
(1) Place all objects in the dbo schema.  This is automatically done if you create all objects logged in as the database owner (sa, for example).
(2) Create user roles so that each role is granted a specific set of permissions based on what the role is.  So, for example an AccountsReceivable role might have access to A/R related stored procedures and views but not to Payroll related procedures and views.  You can have as many roles as you like, so make them as finely granulated as possible.  If some A/R users can look at A/R aging but others can't, create two A/R roles--perhaps ARAdmins and ARClerks.
(3) To satisfy your requirement that a user only be allowed to use certain stored procs and views, only assign those objects' permissions to the role(s) that need them.  Do not assign any permissions on the tables (or other low level objects, such as triggers, etc.) to any role.  Remember that any member of the db_owner database role, or the sysadmin server role (such as sa) will have universal permissions on all objects in your database, so you don't need to grant those permissions.
(4) Finally, place users in the desired roles.  Do not grant rights or permissions to users--only to roles.

By doing it that way, you'll accomplish what you're trying to do; plus, you'll have a nicely manageable security framework for your database.

I see that I didn't make it clear that a user can be in multiple roles.  So if Susie needs to run A/R jobs as well as Payroll jobs, you can place her in both roles.  This way you don't need go through all the stored procs and views, deciding which ones to give to Susie.  Just put her in 2 roles and you're done.  Later, if you add an A/R view, you just grant permission to the AR role, and Susie (along with anyone else in the role) will pick up that permission.

Ken,

Thanks for the response.  That's the approach I've come up with so far, but I find it rather

 I simply want to create a public user that has access to ALL stored procedures and views in the database.  I don't want to have to grant access to these objects individually, because each time I add a new sproc or change the db schema, I have to remember to update the role as well.

So what I've come up with, is under the public role, instead of granting access to the individual objects, I grant access to the database in question (under securables), and then under explicit permissions, I grant access to Execute and Select, and that seems to do the trick.

The confusion lies in the fact that when I RETURN to the public role, under Securables, I don't see the selection(s) that I just made and saved.  They're blank.  The selections took hold though, because the web app now has access to the data.  Similarly, if I remove those items from securables, the web app loads blank pages.  It's not just securables that disappear.  The user's that I've added to the role also load blank, even though they have been successfully assigned to the role.  When I open up the db_owner role though, I see dbo as a role member.  But when I open up public, the role I added isn't there.  But it's taking hold as I said, because the app now has permissions.  Strange...

1.) Why wouldn't the current securables/users show when you load a user/role respectively?
2.) Is there a way I can assign these permissions to a schema, then assign the schema to the role?

I just re-read your remarks about granting EXECUTE and SELECT at the database level.  I have to admit I've not tried that.  If that works, great.  But I don't know what sp_helprotect will show in that case, and maybe you don't care.  It would let users SELECT from any table though, wouldn't it?  Is that okay?  I have to admit this is a very simple approach--but it definitely lacks flexibility, because it can't grow to a multi-role system if that ever becomes necessary.  If you don't care about that, then this seems fine.

Good luck...whichever course you pick.