Most importantly, what prevents a pool from using indistinguishability obfuscation of garbled circuits or Gentry style FHE to deliver (each block) a circuit to a worker that allows the worker to sign valid work, but nothing else? This would add quite a bit of overhead to the signing step for the worker (hitting 1kh/s might even be optimistic, heh) but pooling can still occur and that overhead will only come down in time.
(This is generally an open question going back to at least 2011. My understanding is it is commonly held that avoiding pooling in general is just mathematically impossible, and specifically because of secure function evaluation.)
I doubt that you will hit even 1kh/s with homomorphic encryption. Overhead will definitely be lowered in the future by further researches but it is very unlikely that it will ever be possible to perform encrypted computations with the same speed as unencrypted ones without significant overhead. Creating pool with very large overhead may be possible even now.
Similarly, it seems like a *blinded* multisig escrow (as discussed at
https://bitcointalk.org/index.php?topic=440572.0 and elsewhere) could be employed for a decentralized pool, assuming a specific participant is trusted with redistribution of funds. (However I may have missed a check that would preclude this. It does seem like it would be possible to avoid, and even not all that difficult, unlike the SFE problem.)
This scheme is used to hide both data being signed and resulting signature from the signer. How do you want to apply it here? You can try to hide data being signed from the miner but then miner will need to send each generated blind signature to the server for unblinding. If you are ready to do this than you can do it without any blind signatures, this will move considerable amount of work to the pool and will require very high network bandwidth for the pool.
Of lesser concern, I haven't seen any check during address generation or signing that the address is actually able to be extracted from signatures. Not all addresses will be. It isn't immediately clear to me what happens in this case. I suspect it just means stales that die somewhere under processblock and never get broadcast. (?)
Address is always recoverable from the signature. This fact is also used to make SpreadCoin transactions smaller.
Finally, it seems like the goal of avoiding immense gpu/fpga/asic gains over CPU is somewhat precluded by the scheme itself. By ignoring nonce (other than perhaps the 64-way parallelism you can get "for free" from the masking) and instead iterating on r point values (parallel deterministic selection of k) you can maintain an efficient single-point "wave-front" (and as such a minimum of memory bandwidth utilization) against only one block instance in memory by having each hasher just fill in its distinct signature of the same nonce. By churning just signature+hash instead of nonce&hash+signature+hash you would eliminate the secondary bottleneck for parallelism, and get performance much more comparable to "just" x11 hashing.
Avoiding GPUs/ASICs is not a goal because it is probably not possible. I don't see how can you get any gains by ignoring nonce, this will only make mining slower because by iterating on r values you will have more work to do. You can use the same method that you describe but with nonce iteration; it can save you memory bandwidth but it won't be as fast as X11 because there is simply more work to do.