He referred to people using GPU miners very early on, back in 2009. I don't think he anticipated pools, but never had much comment on it when they did exist and he was around.
He once said this to me in a private email:
Client is a less daunting challenge than full implementation. If it's within reach of more developers, they'll come up with more polished UI and other things I didn't think of. I expect the original software will become the industrial old thing used by GPU farms and pool servers.
BTW, later a good feature for a client version is to keep your private keys encrypted and you give your password each time you send.
So he didn't seem to care much about pooling.
Later in the same thread, he said this:
The simplified payment verification in the paper imagined you would receive transactions directly, as with sending to IP address which nobody uses, or a node would index all transactions by public key and you could download them like downloading mail from a mail server.
Instead, I think client-only nodes should receive full blocks so they can scan them for their own transactions. They don't need to store them or index them. For the initial download, they only need to download headers, since there couldn't be any payments before the first time the program was run (a header download command was added in 0.3.18). From then on, they download full blocks (but only store the headers).
....
With very high transaction volume, network nodes would consolidate and there would be more pooled mining and GPU farms, and users would run client-only. With dev work on optimising and parallelising, it can keep scaling up.
(this was in response to a question about scaling and block sizes in spv mode)
He clearly wasn't worried about network nodes consolidating and people shifting to SPV. We actually ended up with something in between his two ideas for how SPV would work ... every node maintaining an index of every pubkey turned out to be quite expensive, but so did downloading the full contents of every block, so we split the difference with Bloom filtering.
