In other words, because none are ever stored by the implementation, can standard login authentication guidelines also with a 4-digit PIN be enforced to produce theoretically uncrackable combinations where the login username & password are substituted for the PBKDF2 password & salt or vice versa, and the PIN is the number of iterations no less than 1,000?
I see no good reason to make the iteration count configurable, at least within just 1000-9999. Attackers can check all the hashes with the different iteration counts in similar time as only the 9999 one, if they know know the hash and salt.
If you leave the iteration count configurable, it would need to have a significantly larger range of allowed values before it had much of an effect on how an attacker should try to look for a matching password. I.e. several orders of magnitude. That would mean someone willing to wait, say ten seconds every login (tens of millions of iterations) would get some extra buffer.
The standard specifies which of the parameters is meant to be the password (the one used as HMAC key) and which the salt, and while using them in the opposite order may not be insecure, that's what you should use to be safe. I.e. the secret password/passphrase as the PBKDF2 password and the (possibly public) username as the salt.
If the standard username/password rules should not be implemented, why, and what minimums, by any measure such as length or quantity and/or variety of special characters, should be placed upon the PBKDF2 password/salt combination?
Well, pretty much no heuristics can stop a user using a poor passwords like "pa$$w0rd". However, the purpose of KDFs like PBKDF2 is to make the cost of cracking a password higher for an attacker. You can basically subtract ~10 bits from desired attack complexity due to your 1000 iterations.
For example, NIST recommends 80 bits for most secure passwords. You might get away with 70 for a comparable strength. That would mean 12 random base 64 characters (~numbers and upper and lower case letters), but a user-chosen 12 character password would probably have much lower entropy, even if it contained lower-, uppercase and numbers.
As an aside: if you want to guide users to choose good passwords, I would rather not set any limits (especially maximum length or minimum character set) and point users towards something like Diceware or password managers.
