For one, I suppose the system you're planning is for a limited use case, since I don't think it should be impossible to demand a bit more from passwords in general use: even Stackexchange requires eight characters with numbers.
In a way, one million possible codes is both very little, and large enough. If an attacker gets your password database, and can try to crack the hashes off-line, they'll be gone in an instant. Even if the hashing would be slow enough to only allow testing for ten codes per second, the whole keyspace would be through in a bit over a day. It's not going to be that slow.
On the other hand, since you can rate-limit on-line login attempts, it should be quite controllable. To get just a 1 % of guessing a passcode, the attacker would need 10000 tries. That shouldn't be usual, especially from a single source IP or against a single account, and you should block the source at that point, and consider locking the account. (If you have lots of users and are attacked by a botnet, then it's harder to detect.)
Though with digit codes, you must make them random, instead of letting the user decide. Otherwise they'll just pick dates, making the effective keyspace seriously smaller. You already touched this when planning a random reset, but it has to be random to begin with, otherwise finding out people's birthdays will be too profitable.
As for the automatic changing of the PIN, heck no. Apart from the spam others have mentioned, it might also lock out the legitimate user if they cannot access their email just at the right time. And if you do no rate-limiting at all, they won't have time to read their email before the attacker has churned through another 20 attempts, and the code changes again... Then again, if you do rate-limiting, you could just lock the account on purpose for a while.
Of course, locking accounts is a a DoS vector, but it's a trade-off you need to choose. Do you want to prioritise locking out the bad guys or making sure the good guys get in?
Would the automatic changing make the code harder to guess? Well, yes, marginally. For an unchanging passcode, you'd have K in N chance of guessing it, when doing K guesses against N possible codes. For a changing code, the chance of guessing it is a constant 1/N for every guess, or 1-(1-1/N)^K for K guesses. Works out to about 500000 vs. 700000 for a 50 % chance of getting it right. It's more, but in the same scale. Do you want to allow those hundred thousand login attempts in the first place?