No worries, - as Ian says, it can be hugely frustrating - especially if the documentation is not a step-by-step list of instructions, but rather links to generic (and therefore not very task-specific) documents that can easily confuse rather than clarify the processes.
As the User Registration Solution Pack should really take just a few minutes to set up, I would prefer to see every tiny step detailed in one single document with a view to getting it up and running on your remote (live) server, with perhaps a link at the very end for people who want to set it up for use on a testing-server on their own local machines (*when 'root' actually would be used as the database username).
As it is, it is easy to be side-tracked into thinking that the username 'root' (as shown in the linked instructions) has to be involved somewhere, when in fact the user name on the final uploaded connection file will never be 'root' (unless Mr Root buys the URSP for uploading to www.root.com).
* The username 'root' is only ever used when testing pages on a local testing-server, and refers to the 'super-user' name for the mySql database that is installed as part of that testing server on your local machine. The password to go with it would be one that that was chosen by the person installing the testing server/ mySql on the local machine (and it's quite possible that a password hasn't been set at all). All database usernames, passwords and logins that are in connection files for upload to the remote server will almost certainly be decided in whole or in part by your domain name hosting service.
And it's correct that you can't have two tables with the same name in the same database. You either need a new database, or the sql needs to be changed to create a table called 'users2' (for instance) and the URSP scripts edited to use that table name instead of 'users'.
The User Registration Solution Pack bare-bones example here has been altered to use 'users2' table in the database.
Sorry about the waffling. Post back with any problems or queries.