Should login id and password be stored in separate table
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.