I think that "database abstraction layer" isn't really what you think it is, or at least your view is incomplete. Microsoft's Entity Framework, as well as other ORM tools, are "database abstraction layers".

The purpose of a database abstraction layer is to provide an interface to your data store -- it isolates the data store behind a consistent API, and you code against that API instead of directly against the data store. In theory, by using a DAL, you don't have to care about the actual data store, you code against the DAL and the DAL handles all the gory details of accessing the data store, and it "just works". In reality it's rarely that simple, but that's the goal at least.

In the sense that stored procedures and views in a database can provide a consistent API, they could be considered a DAL, but generally that's not what a programmer would consider to be a DAL.

Whether or not you restrict database access to sprocs and views, you'll still have issues with altering the *structure* of the database -- it won't make things any easier, because a structure change will usually require a correspondeing model change in code, because a structure change changes the interface in the DAL. But using sprocs and views gives you much more flexibility to alter the underlying *logic* for data storage and retrieval without requiring model changes in code (as long as a change to the logic does not change the interface). Sprocs and views also help with management of security.

That said, current ORM tools (including current version of Entity Framework) can work with stored procedures and views. I'm doing it myself right now, in fact (EF 4.x...accessing SQL Server 2012 database via stored procs and views, working fine so far but it takes a bit of extra effort). Other ORM tools have similar capabilitites from what I understand but I don't have any experience with anything else at the moment.