This sounds like such an obviously great idea that I don't know how I haven't heard it before. Can someone who understands how databases are built explain why this isn't an obviously great idea?
However, another approach would be extension of the database's client-server protocol and driver(s) such that the hash verification occurs within the application tier (as part of the driver). Or, moving further along that path, the field could be annotated in your ORM, exposing special set and verify methods. But at that point, you're very close to the current condition, where the hashing occurs within your web application framework.
Or hashing could be done on the client side.
Only if you use a proper PAKE. A vanilla password hash is still a bearer token on the wire.
My POV is you should be able to verify user sign-in with something like "SELECT COUNT(*) FROM users WHERE email = 'maaku@hellokitty.com' AND password='hunter2';", which has the added bonus of not informing the client whether the query failed because the user didn't exist, or because the password was wrong. Imho, all queries for the column content should simply fail.
I would add that the 'bonus' of not informing of the correct error provides minimal security gain and hurts usability.
This would be a bug. There should be no way for someone with my e-mail address to determine if I use any particular service.