We use a DAL layer that not only does the SQL stuff but handles the abstraction. The DAL layer's responsibility is to take in a generic object called a data transfer object. The data transfer object contains a list of DAL POCOs. The DAL looks at each POCO (we decorate the class with attributes) and dynamically generates a mapper class based on the object type. From there, it is just mapping POCO properties to stored procedure parameters. The DAL is very simple, just Save, Delete, and Query on the interface along with a custom command when you want to do something else (call a stored procedure other than the basic Insert, Update, Delete, Query ones) for some extendability.
The DAL doesn't really care about the Domain, its tied to the schema. So, the POCOs that the DAL uses may be mapped to different domain POCOs in the domain layer. So there could be an intermediate layer in some cases, but you could use the POCOs that the DAL is using as they are just state objects and contain no methods or logic in them, but somethimes the domain and DAL don't really match up so thats when the domain would be responsible for converting the domain object to a DAL object/POCO.
From a DAL standpoint, currently we are supporting 50 out of planned ~200 tables with this pattern, I guess this is an home grown ORM lite. With some code generators we implemented, most and the mapping code (tedious glue code) is handled automatically, so we can concentrate on the business and presentation logic.
But that's how we did it with 100% Sprocs.