I'm not sure that would result in less lag, common sense dictates it would result in more. If all the rendering is done on a remote "super-network" (funded by who?) then that hugely increases network loads on the server and the clients. You know how long a blockland screenshot takes to load on the forums, so how do you imagine transferring 200 of those images per second, to a general small gaming audience of about 50-60 people. Assuming an average screenshot is 100kb in filesize. Multiply this by 200 and you've got 20,000kb being transmitted per second. Multiplied by 50 and you have 1000000kb being transmitted per second from the server to the 50 clients using it. Thats 1gb per second - your super-network must have a great internet connection.
Secondly, with this added network lag and remote rendering, you now have no client-side prediction so instead of the game continuing when you get a lag spike, the game will just standstill. Controls will also have a huge response delay because you have no client-side prediction again. So when you press A, you have to wait for that information to be transmitted to the server, transmitted to the super network, processed, checked, rendered, transmitted to the server and then transmitted back to you and loaded. Thats a pretty crappy input pipeline if you ask me.
Apart from those minor technicalities i've outlined, I'm sure you're onto a real winner here. Make sure to patent your idea so all those huge experienced technology corporations don't get their hands on it!
Edit: And if your rendering pipeline relies on half the users on the game being afk, I think you'll experience a few other problems.
