Should I create a separate database table for temporary users

Whether you use one table or two, you should be able to insert all the data needed for in a single transaction.

More importantly, you should not store the password, but instead store a password hash. Here is one post on using a password hash such as SQL Server itself uses. This is using SHA_512 hashing with a 32-bit salt.

http://sqlity.net/en/2460/sql-password-hash/

This way you never store the actual password. At the time of the creation of the password, you need to share the password with your new user. And ideally force him to change the password at first use.

Each time a new password is created, you must, of course, update the hash to match the current password. Which means that you must manage all password changes, not just the initial password.

EDIT Re: "how can I am able to enter employee details in employee table and generate user id / password for user and store in from separate table in one action."

You must do the work in a transaction. Here is a sketchy outline using 3 stored procedures. Of course, you need to write the actual code:

BEGIN TRANSACTION; 
   EXEC InsertNewUser @Name='UserName', ... , @NewUserId INT OUTPUT; 
   EXEC CreateNewUserPassword @UserID=@NewUserID, ..., @Password NVARCHAR(128) OUTPUT;
   EXEC SendPasswordToNewUser @NewUserID, @Password; 
COMMIT TRANSACTION; 

By collecting the new @UserID and @Password values you can use them in the following steps.

Without seeing the table schema, I see two options:

1. Adjust the schema so that the Foreign Keys(FK) are not part of the Primary Key(PK); only the AUTO_INCREMENT column is the PK. The Foreign Keys can still be Unique Indexes to prevent multiple likes of a particular track by the same user. This won't work of course if the FKs are part of a partitioning scheme.
2. Take out the AUTO_INCREMENT column and add a TIMESTAMP(0) DEFAULT CURRENT_TIME column. The timestamp column will take up as much space as an INT AUTO_INCREMENT column. The downside to this is all rows before adding the timestamp column would not have an order.