It gets more complicated than just metric or imperial. There are also things like "metric feet".
A metric foot is 300mm long. It's ~5mm short of an actual foot. Wood, annoyingly, in the UK comes in metric feet lengths. Yes, that's right. You can't buy an 8 foot spar. You can buy a 2400mm spar. The problem arises when you actually need 8 feet of wood because 2400mm is nearly, but not quite 8 foot.
The reason there are different conversion factors is that the units all arose for different things. A foot is about a foot length. A yard is about an arm length. An inch is the last part of a thumb. That sort of thing. A furlong is the distance a couple of oxen can pull a plough in one go before they have to rest. A chain is the width of a bit of land of an acre in area and a furlong long. An acre is the area you can plough with one plough team in a day -- and hence varied depending on what you consider to be "a day", "can" and "team" and hence on things like what the soil there is like.
All of these were then sort of standardised over several centuries, but the measurements needed to be close to what they'd always been, so they ended up with "funny" conversion factors between the units.
If you're doing engineering in imperial (my Dad used to) then yes, you get used to doing conversions and using things like the "poundal" and the "thou". I grew up in the metric era, but I grew up in a household which measured things in imperial. In a discussion in the office a little while ago, I described something as "about 10 thou" and one of the guys here said to the other (younger) team members "See!!! I told you it wasn't a made up unit..."
"Of course, this trick only works if their spawn-rate is 1:1 with their lifetime"
It's perfectly reasonable to include some downtime as a ratio inside the particle data. You just draw a degenerate quad/tri if the particle is currently not running. By tweaking the origin times/respawn ratio times you can then generate effects like a fire which flares up and dies down.
"Where the hell does government get the right to tell me I'm no longer allowed to use DDT to kill the insects in my garden."
DDT's an interesting one. There's a body of opinion that banning it has killed more people (from malaria) than using it would have done. That is; although it's dangerous, it's better than the mosquitos having a good time.
Hell, most places don't even bother writing things down properly. I think outsiders overestimate how organised software companies are.
Generally; don't write design documents. You don't need them. You need them to communicate a vision to 100 people. If you're writing a game on your own or with two or three other people, it's paperwork you just don't need.
If it's game design you're interested in... then design games.
Don't design computer games, they take a lot of faff. Go design board games. Raid copies of monopoly and other board games for parts and dice. Draw up your own boards on big bits of cardboard. You can make decks of cards by buying small packs of index cards. There are also other game pieces available from companies like http://www.rolcogames.comhttp://www.p4g.co.uk/http://www.dice.co.uk/ and http://www.gameparts.net/ (at least a couple of these places will sell in really small quantities and some of them do "prototyping" kits containing sample selections of components).
Writing rules is easy... playtesting them and fixing them so they work not so easy -- but this is the important part.
The skills you pick up here about designing fun and fair games transfer to computer games.
"1) Would a commercial enginge available for Indies (up to 5000$) allow this level of costumization"
No. You're going to have scalability issues. Why? Because most extant MMOs (and hence their engines) are based around rather static world geometry. Minecraft keeps the geometry local and generates by psuedorandom techniques when required, saving the areas as it does so.
In order that you can have a landscape like that but which can be altered by any of the players, you'll need to store the whole landscape (in the way Minecraft does) but also to send deltas in that landscape to all players who can see the change (and you'll need to determine who can see each change). In addition you not only have to tell players connected now about changed geometry, you'll need to tell all the players who will reconnect later about changes.
It's not impossible, but it's a difficult problem to solve well. Which brings me onto the next part...
" If nothing of the above works for me then I would have to build it, with something like Boost as you suggested, nfries88. How long would that take me, providing I can work lets say the average 40 hours a week in the project. 1 year? 5 years? 10 years? (I can't spend more time than that"
If you are at the stage of referring to Boost as "something like Boost" then you have a number of things ahead of you.
You need to;
1. Get good at C++. 2. Get good at games development. 3. Write this game.
There's a reason why, when I go shopping for good C++ developers, I'm looking for people who've been using it for several years. It takes of the order of 10000 hours to get good at something. There are about 2000 working hours in the year, so 5 years is the point at which people could be good. 5 years does not MAKE a good C++ developer but the chances of someone with a year of it being good are so small it's not worth worrying about. It's not that I wouldn't hire them, but I would be aware that if I hire them I'd be expecting to have a lot of conversations about segfaults.
Games dev is a related but different set of skills. It's about understanding how to handle game loops, to defer doing things, to cache things, to handle inputs in the right way, to look at a set of problems and understand how to solve them not just in performant ways but within the envelopes of games. To understand things like "good enough is good enough", "faking it is cheaper than doing it" and "neither you nor the player needs this". These are skills which also need honing. They're less technical than the development -- they're about psychology, project scope management, product ownership and control. But they still need to be learned and practiced.
I'm telling you all this because "1 year is a fair estimate for a basic Minecraft-like MMO. Certainly less than 5 years" is almost certainly untrue. It's not a malicious lie; it's an untruth born of optimism. But it's still unlikely to be true. And you'll be disappointed. Minecraft's a tricky problem to solve -- and to be clear here, Notch is NOT a beginner. It's not his first released game nor is it his first released bit of software. And it's taken him a year. And an MMO version of it is a step further on.
Why DOES everyone want to write an MMO as their first game? What happened to implementing things like Qix or Pong or Breakout so that you get the hang of the basic principles before leaping straight into client-server software that is complex by anyone's standards?
 Yes, I know everyone here is an EXPERT in C++, and that you all got that way in just a couple of weeks and that you're all exceptional in this. So don't even bother telling me.
 This is a common commercial error in hiring processes.
It's not actually that hard to do some of these things.
Were I to have a go I might be tempted to start with Linux as a base (because the software is much more open). There are extensions to X11 which allow you to inject keypresses/mouse moves into the system from other userspace applications.
Libusb now allows you to write USB device drivers in userspace. As long as the device produces USB and you can find what the protocol looks like, it shouldn't be too complicated to run it. Read some bytes, parse them, emit events, go round in a loop -- you could possibly even do a lot of this in a scripting language rather than needing C. You'd then be able to tweak the translations to fit the situation.
Once you've got X11 events happening, there's a whole bunch of games available -- nintendo emulators, spectrum emulators and a lot of free linux native games; including some fairly well made clones of PC games (eg; OpenTTD or Widelands). Plus there are a bunch of other tools to do things like emulate keyboard input using only mouse movement, so it would mean general computing applications would become accessible.
And all of this can be done without any huge investment so you can afford to try things without sinking money into it while you're learning the techniques.
It'd be a bit lashed-together to start with, but it's an entirely approachable project.
"You can have just two threads, the main game thread and the background-loading thread."
A reason to have many threads in the background is to issue many IO requests. The reason to issue many IO requests is to a) saturate the disk bus (because you want this stuff loaded) and not have any dead time and b) to tell the OS about all the things you want to load. Why? So it can then optimise the loads; suppose you want to load 5 files all on different tracks on the disk. If you tell the OS about all of them (by asking for them) then the OS can order the accesses to go across the disk in the optimal seeking pattern; It may make sense to load #3 first, then #2 then #5 and so on. The OS will know more about how to do this than you probably can because it knows more about the storage device.
Windows overlapped IO does this without the overhead of all the threads (each thread requires a non-trivial amount of memory to be allocated).