I'll sign up for the beta test - nice to see some originality for once.

I do, however, see a few issues with the proposal.  Some (hopefully all) are probably addressed.

1.  Transactions.  If the network grows to any decent size then there will frequently be multiple transactions created at the same time.  This poses a massive problem as:
a) If transactions don't have to be ordered in the ledger then it allows the back-insertion of double-spends (i.e. spend something legitimately then, using 2 of your own hatching nodes, spend it again later but with an earlier time-stamp).
b) If transactions have to be ordered - i.e. once one is accepted any others must be after it - then that is surely going to lead to lots of orphaned transactions and ones which have to be reprocessed to get back in sequence.  That would then allow anyone to grind the network to a halt by broadcasting a fairly modest quantity of transactions.

2.  Voting to create new EMUs.  This talks about voting on a random node.  How is this randomness enforced?  Clearly it can't be implemented by use of a RND function in the client - or people could change the code, create lots of semi-clients (i.e. lightweight ones with nothing much other than voting mechanism) and vote yes to a seed node they run themselves.