It would have to be that complicated. A large reason why the IO on a pool server is so high is that miners want low variance and and real time stats (i.e. thousand if not millions of low difficulty shares). In a setup like this the node isn't really a "money maker" and the work load can be much lower. With ntime rolling it is very possible that the pool server would only need to provide a single work unit per router per block. Likewise for the "lottery" you don't need routers to return a lot of shares. The share difficulty can be set relatively high such that a router may only return 1 share a week. The pool would convert 1 share (and only 1 any excess shares rollover to cover variance in future weeks) per week per router into a ticket and lottery off the week's proceeds. The router would advise the user if they won (maybe even a blinking Bitcoin LED).
The load on the pool server can be reduced to a negligible amount. Per router it would be roughly 1 WU issued per block, and 1 high difficulty share to verify per router per week (or maybe day for lower variance). If the pool could maintain 0.1% of the network hashrate it would on average solve one block per week.
Still I think this type of setup makes more sense in a donation/charity model. Buy a cobranded router from your favorite non-profit, plug it in and collectively help the non-profit raise revenue.