One of the potential problems I can see is that you may have to tweak the "reduced" difficulty level in some way so that it really is about a 1 in 40 chance of getting a successful hash.  It would seem to me that a reduction of even a couple of bits in the expected hash would have major consequences in terms of how many "reduced difficulty hashes" are created and it is possible that reducing the difficulty to 1/40th of the "official" difficulty level may create many more "successful" reduced difficulty hashes than 40, perhaps even to a higher order of magnitude.  This is something to test with a successful experiment of this idea to see just how it might turn out.

Furthermore, it is also going to be random in terms of how many reduced hashes are going to be created per successful hash cycle, as you are dealing with probability here and not mathematical certainty in terms of how many are going to be generated by the "farm" even if it does produce in this example on average about 40 "reduced difficulty hashes".  It may still be worth the effort if it turns out that on average that is all you have to spend for an increase in successful blocks created, but it will be some blocks where the hash farm server makes a bunch of coins for the server operator and other times it may be at least temporarily a loss.

Another potential problem I also see is if you happen to be requesting hashes where you've received a couple dozen reduced hashes and then the network has a huge spike in difficulty.  This is a potential liability issue so far as the "owner" of the hash farm server is concerned, as it would substantially impact the "profit margin".  Think of it this way:  If the current difficulty is at say 800 and you've received 30 hashes with a difficulty level of 20 (1/40th of the difficulty, as you suggested here), then the difficulty increases to 1600, it is very likely that you may have to plow through another 30-40 hashes at the new higher difficulty level of 40 before you get a successful block into the chain mining the coins.  If in this example you are still paying out 1 BTC per reduced hash, it could get very costly for the person running the hash farm in this case.  It may wipe out any profit earned and certainly is another potential liability issue to think about.  I'd have to think through the statistical probability on an increase of difficulty some more in terms of giving some hard numbers, but it is something that should be accounted for.

Then again, difficulty could drop brining in at least statistically more money to the server operator.  The current tendency is for increases of difficulty, however.

Otherwise, I think the basic concept as outlined here is pretty sound and would tend to work rather well.  Almost too well as I could see this being put into a botnet and having the computers in the botnet be sending back potential hashes without having to worry about any payments.  Network bandwidth would be trivial and almost unnoticed, and you could even "throttle" the CPU bandwidth or throw it onto the GPU instead.  I have no doubt that eventually somebody is going to build one of these botnets if it hasn't already been built for Bitcoins.