About 20 years ago, our database had a table that contained a single row whose purpose was to add an updated key code to any of several other data tables when adding a row. This may be still in our application, but it's not good practice now. I don't precisely understand your examples, and if that is what you are considering, don't do it.
As for primary key though - not every table needs a unique row key, but in case you may need a key later, it's simple enough to include a "row_id" with arbitrary value automatically set, such as 1, 2, 3, etc. In order to use this as a table key, such as by defining a "foreign key" relationship where the key value stored in a different table points to the corresponding row in this table, you should create a constraint which asserts that the key is unique. This can be either a primary key constraint or another uniqueness constraint. A professional database system will typically create an index on the key's columns to select each key value efficiently in the table.
Specifically in Microsoft SQL Server, which I know, and presumably also in any other useful SQL relational database system, a table can have one "clustered index" whose effect is to store data with sequential values of the key value together, so that they can be quickly read together. This is not necessarily the order in which data is added; for instance, you may want to organise data by customer ID and then by date, so that all records for one customer are bunched together. MS SQL will create a clustered index for the primary key unless you use the words "Primary Key Nonclustered",
MS SQL then bases any other index on the clustered index and includes the clustered index key, which means mainly that a short key (few bytes) for the clustered index is usually best. An auto-incrementing table column - you usually ignore it when inserting data and it is automatically set to the next number - is good for this, if it's acceptable to have table data physically sorted in the order of inserting the rows. That often is what you want. Also, the clustered index should be created before other indexes; this isn't compulsory, but when you create or change the clustered index, other indexes are re-created as well, adding to the time taken.
Semantically, "primary key" also should be a meaningful element in data, and not a random number that you arbitrarily associated with the meaningful data in a row - unless it becomes meaningful from then on. And @RDFozz made the point that using another value as the key (username) and then having to rewrite the data in all tables so that data previously held with username1 now has username2, is an inconvenient exercise. Better to have table column Users.arbitrary_row_id_number as the primary key, and username as another column in the table that can be easily updated in one place. You even could be caught out with "country code" if mainland China takes over Taiwan, or if Puerto Rico is promoted to a state of the U.S.
With or without that extra care, most of the time, you can simply declare an appropriate "primary key" for the table, and benefit from useful indexing as well. But take care. One of our tables has a file name as the primary key - people send us files, named with date, time, and account code. But it's over 100 bytes long, so it is not a good clustered index key; that's where an auto-incremented number (4 bytes) is used. The filename is primary key, but it is not the clustered index key.