The solution to my problem was a fairly simple, others have contributed to this answer but it wasn't entirely accurate. If you utilize an HA system you cannot have the Health Usage database in the high availability during patching as it causes the PSConfig application to error, this is what others have said and it is accurate. During the patching process the application attempts to set the database into single user mode and this cannot be done while the database is participating in a database mirroring / high availability configuration. This is what was causing my error in the first place.
If your system utilizes multiple SQL servers, if you fail over to your secondary node your system will throw critical errors until you create a new database on the node that does not have it. This is acceptable by some however I felt it was avoidable.
To proactively prevent this, all SQL servers in your high availability farm should have the database setup manually but not participating in the HA. What I did was I generated a CREATE TO script from the primary node SQL server for this database and go to each server and execute it on each server. I got errors regarding maximum key length and index errors but they were all warnings and didn't appear to effect the system that I could tell. I also received stored procedure errors noting that dependencies were missing, again, I believe those can be ignored as well as they were more than likely caused because of the order of generation of the automated script and would be created later. Use this at your own discretion. The alterative is to use the set-SPUsageApplication command however I believe this may cause additional problems if you have another database somewhere else named the same, and if you try to specify the same GUID directly it may not work as well for a duplication error. I was unable to get it to work myself, in either regard so this is why I chose to script it directly to the SQL server, hoping to avoid duplication issues.
SharePoint doesn't know your system uses a high availability so the simple solution is to backup the database and restore it on each server, but in my case I had 30GBs of data in my primary node database so I could not do that either. The content shouldn't matter according to other posters since the data is transient data. Either way, SharePoint doesn't know those servers need it setup and since you cannot utilize the high availability to generate the database on each server (which imo would be far simpler) it must be done manually for each server and this is not outlined anywhere in any whitepapers that I saw so I had to makeshift something that would solve the problem.
While the system will function without the database, you will see critical errors. This is the only method to avoid critical errors and additionally without the database in existence, PSConfig will not run as well until you create the database on a node that it does not exist in. This was the only way I was able to resolve it in an acceptable manner that stopped errors on my sharepoint farm. As this is obviously not officially adopted by Microsoft at the time of this post, use at your own discretion.
So the answers to my questions above:
1) The database connection string is configured in the original starting GUI in the PSConfig. If you use the command line it will pull the database setup from the SharePoint_Config database shown in the central administration under the System Settings -> Manage servers in this farm section. You can utilize an HA listener as long as the health usage database is not in the high availability configuration and accessible to the listener.
2) While this database is not breaking to SharePoint operations if it doesn't exist, the database is critical to proper operations and must exist in your farm, if not for day to day operations and preventing errors but also to properly patch the application as PSConfig will attempt to alter the database to single user mode during patching and will not function if the database does not exist. Additionally it will throw critical errors to your application errors log in the OS if it doesn't exist but as Trevor stated above, it will not bring your system down completely and can be handled without end users noticing any problems on their end regardless of its existence.
