Yes, of course with mining-diversity=0, any miner can generate a block at any time, so this is not safe.
As for higher mining diversities, it's true that nothing prevents an attacker from generating more blocks than other participants, by always jumping in as soon as they get a chance according to the diversity constraint. But then, they have to wait until their turn again, so it doesn't do any damage to the overall consensus process. And unless there is some reward for creating a block, this type of "attacker" has nothing to gain.
Your idea of using the previous block's hash to choose the next block creator is interesting, although it is susceptible to manipulation as well. It might just be simpler to say that nodes don't accept one block too quickly after the previous one, and when presented with a fork they prefer the side with the miner whose last block was furthest in the past. This rule cannot be enforced in terms of chain validity (since the arrival times of block is not a consensual fact), but at least it will encourage honest nodes to prefer forks from other honest nodes.
In any event, there is no ability in MultiChain to do this yet.