If you have a keyed family of $2^b$ distinct permutations $E_k(p) : \{0,1\}^b \times \{0,1\}^b \to \{0,1\}^b$ over $b$-bit blocks, and select an independent, uniform random key for each plaintext block, then your proposed mode is perfectly secure for the same reason that one-time pads are: for any candidate plaintext/ciphertext pair $(p, c)$, there exists a key $k$ such that $E_k(p) = c$. You securely show $c$ to an adversary, because given that $k$ was selected uniformly at random, with the information they have every possible plaintext is equally likely.
We don't even have to assume that the family $E_k$ is pseudorandom for the above to work. For example, $E_k(p) = k \oplus p$ is not a pseudorandom family, but is perfectly secure when used in the mode that you propose. We just need $2^b$ distinct permutations—it doesn't matter what those permutations are!
However, if your blockcipher provides fewer than $2^b$ distinct permutations, then you no longer have perfect security. In this case for some ciphertext/plaintext pair $(c,p)$, there is no key $k$ such that $E_k(p) = c$. A computationally unlimited adversary that observes $c$ can therefore learn that $p$ is not the corresponding plaintext, and this violates perfect security.
So your question comes down to whether your blockcipher has equivalent keys. Some do! For example, the Tiny Encryption Algorithm (TEA):
TEA has a few weaknesses. Most notably, it suffers from equivalent keys—each key is equivalent to three others, which means that the effective key size is only 126 bits.
TEA does have a 64-bit block size, though, so having "only" $2^{126}$ distinct permutations would not render it insecure in the mode you propose. But AES has a block size of 128 bits; therefore if AES-128 has even just one pair of duplicate keys, then your AES-based proposal is not perfectly secure. (See also: "Do all ciphers have equivalent decryption keys?")
So the big lesson here is this: blockciphers are designed to be pseudorandom permutation families, but this property is neither necessary nor sufficient for perfect security in the mode you propose. Apples, meet oranges...