From a security standpoint, the threat is what happens when the underlying storage is exposed in any way, not just a sql injected select * from users; statement. Do you trust your administrators? Even the one you just had to let go? Who else has access to the box? Is it a virtual machine at a third party company? In the cloud? That is why getting hashing right is often emphasized first and foremost, so that user passwords have some defence even against an authorised user.
That said, I think controlling access via views would be beneficial, such that you can only execute pseudo-instructions "insert user", "delete user", "does user exist" and "are these credentials valid" from the perspective of your web app. This prevents enumeration except by repeated calls to the database with a known user identifier, which is better than allowing the attacker to grab the entire database. You're reducing the ease with which an attacker can grab that table in the case of any potential compromise/unforeseen vulnerability in your code or framework. The only question is compatibility with existing frameworks, although many provide the ability to extend or implement custom authentication backends.
On the subject of hashing, use PBKDF2 or bcrypt or an equivalent slow hash key derivation function with salt, not just a hash with salt. A decent article on the subject will explain this stage (sometimes they recommend repeating a hash for several thousand iterations; it's essentially the same idea).