I would really recommend that you engage a consultant at least to assist you in planning this process. Attempting to do a data migration while very new to the platform and with no exposures to the pitfalls involved can place your organization's data and data integrity at risk. At minimum, you should practice and evaluate your results on a sandbox.
The full answers to your questions would literally be a book on Salesforce data migration and ETL. I'll try to answer them briefly and give you scope for more research.
Q: What do I need to do in order to avoid duplicates?
There's some more background nuance here. If you're moving from Org A to Org B, and Org B is empty, you have less to worry about. Preferably, you'd want to deduplicate the data inside Org A prior to initiating the migration.
If Org B is not empty and you need to deduplicate the data as you migrate, your situation is quite a bit more complex. The last time I executed such a process, I worked for several weeks closely with the involved business users reviewing reports of the top-level records in both orgs to identify duplicates and map them. In that case, it was just Accounts. If you need to identify duplicates across multiple records, your situation will be a good deal more complex. You may wish to use a commercial tool to make this process easier.
-Q: Also, step by step, how do I use Dataloader to do this perfectly?
This is way too broad to give a complete answer. At the top level summary, you will need to execute the load of your objects in dependency order (parents first, then children, with junction objects after both parents).
My preference is to maintain a global ID file, a spreadsheet where I collect the results of each load in a simple two column layout ("Old Id", "New Id"). That makes it easy on each file you load to do an INDEX()/MATCH() construct to map each parent Id reference column to the new Ids of the inserted records in the new org.
That is also the step at which, for example, you might remap child records from parents in Org A to identified duplicates in Org B.
-Q: Do I need to move irrelevant Users also? Can the Accounts exist without the user who created it?
It's up to you how you handle the OwnerId column. You can pre-seed your Global Id file as described above with a mapping between the old Owner Id and the new Owner Id.
-Q: Do I need to do anything with ID's if so what?-and please be specific.
This is the question that raises the biggest concern for me. Doing a large-scale org-to-org migration absolutely requires that you be comfortable with the structure of the Salesforce data model, including all the permutations of relationships (foreign keys). If you don't have that comfort, hire a consultant.
-Q: What batch size should I set Dataloader for?
Highly org-specific and depends on how much code you have running on each object, and how well that code is implemented. You may have to experiment in a sandbox. The default is 200; you can set it as low as 1 if you need to to get past lousy code, but it will take far longer.
-Q: Is there anything else that I'm missing?
Data Loader is not your only option. I would strongly consider an commercial product that is designed to do multi-object backup and load (there are several; I'm not specifically endorsing any of them), or an open source solution like Amaxa or even CumulusCI (although note that there are significant limitations of both of those products and they might or might not meet your needs here).
Disclosure: I'm the author of Amaxa and on the CumulusCI team.
