That's several questions.
1. This post has some example files of how to script creation of Accounts with Privilege Sets
It uses a rather lightweight security method of password storage (as I recall).
2. You can set Record access View and Edit restrictions in Accounts and Privileges for a Privilege Set. You need a field in each record which has the Employee Account name. How you get it in there is up to you (could be assigned manually), but the easiest method is to Auto-enter on Creation, Account Name (down at the bottom of the auto-enter options list).
Assuming the name of the field is Emp_Account, the record-level access calculation would look like: Get ( AccountName) = Emp_Account
You'd need to do this separately for each table where this is relevant.
You should be aware that View restrictions cause a big performance hit, as FileMaker must evaluate the test for each potential record in the found set. The good news is that FileMaker does this automatically for any Find, so once set it does not require much scripting for Finds. You must however write your own "Show All Records" script, as otherwise it does what it says, ie., shows all of them, with <<no access>> in the fields of those not matching your restriction calculation.
Another way to do this is to only show these records in portals, where a relationship can restrict users to their own records. But then they cannot easily work with found sets, etc.. Perhaps a combo of the above (show latest records) with a switch to a List view via relationship.
Basically, View restrictions are either quite slow in large databases and/or a fair amount of work to make them appear to work transparently. I think they are well implemented by FileMaker; so it's up to you to make it all work well. Whenever I have implemented them (on request) in tables with a lot of records (tens of thousands+) I have later been asked to remove them, because of speed loss.