Securely manage and dynamically create multiple databases
It seems like a limiting factor here might be that we don't want to make a connection string for each client and separate the user used to connect to the DB back end that way.  As a result we are using a SQL Database user that has full access to all the databases, with them really only needing access to 1 DB that being their own.  In the current security model, if a SQL injection attack were to occur, they would be be able to have access to all databases, instead of just the 1 user database they need due to the connection string.

To resolve this issue you're proposing that you create a database to hold customer information such as login ID and password to their SQL Server database user which has access to read/write/execute, and want to know if it provides any benefits over the current model.

You could do as you proposed by having a user that can only accept sanitized and paramterized stored procedure queries with being granted only execute permissions on the master users/login table.  Once you get that value based on your uniqifier (be it ID, company name, etc.), you are mostly protected from a SQL injection attack.  An extra level of defense would be to encrypt the value within the DB and have the app decrypt the username and password before passing it in.  This would fully protect you from someone getting your username/password from SQL Injection even if they did manage to pull out the raw value from the DB engine.  They would have to also get the decrypting private key off the web or key server before they could read the credentials needed to access the databases.  

By doing this you are at least protecting your company from having someone make a change on every single DB in the enterprise if they were to break in, and they would be limited to just messing up 1 customer; unless of course they got your private keys or the decrypted password list some other way.

This is of course just a quick review of what you proposed.  There are tons of different ways to do security and this might not be the most ideal in your scenario, I don't know what would be best from the limited info, but it would work to answer your question and give you that extra line of protection of encryption, multiple places they'd have to break in, and separate users owning each DB which is always nice.  

SQL 2016 has some great new security enhancements you could utilize too if you want such as always encrypted data and saving your keys elsewhere if you wish to take this to the next step.