That is one of the issues I had in mind. But what about other data, how are you going to access data in other tables which are not connected with any user (universal)? If you want to change any of those data how are you going to synchronise it for all other users? If the logged in user has access only to one database then to keep the security your application should not be allowed to access other tables.
Another one would be adding/removing users - you would need to create and drop databases for this operation, which require CREATE/DROP DATABASE priviliges - and recreate all tables on the new database. Are you going to do this manually?
Also, things like listing all users to see which ones have been logged on lately, or for any other reason like statistics, getting their data, etc. That's all awkward if they are scattered accross databases.
I'm not really saying this approach is wrong as I'm not a security expert, I just can't wrap my head around such an extreme solution. And I'm not sure how much security you can really gain from this. I don't think that banking systems ever create a separate database for every one of their millions of users - there must be better ways for securing the database. I'd be glad to read what people who are more expert on security than me have to say.