I can't see how RSA (assuming OAEP padding) can be used in normal block cipher modes. Its output is likely not pseudorandom, so it can't be used in CTR, OFB, or CFB mode. Its output is too large to be fed back in, so it can't be used in CBC mode. Using it in ECB mode would have the problem that blocks can be moved, duplicated, deleted, and replaced just like if you use ECB on a normal block cipher.
You're right about the CBC, OFB and CFB modes. Using RSA as drop in replacement will be troublesome anyway, because it would run into practical issues besides the security related ones already mentioned by fgrieu. Will the padding mode be compatible with such large block sizes? Will the implementations? What about buffers created to be about the same size of the plaintext input?
ECB in my opinion has the best cards. The main issue with ECB is that repeating plaintext blocks will be seen as repeating plaintext blocks by an attacker. This problem however is not present if you'd use RSA with e.g. OAEP padding. OAEP padding already has a random component, so you would not be able to see the repeating pattern.
You also state that ECB allows blocks to be "moved, duplicated, deleted, and replaced". This is however not just a property of ECB mode; it's a property of any mode that doesn't include integrity protection and authentication. You can simply remove this problem by authenticating the ciphertext with a digital signature - the asymmetric equivalent of a MAC. If you assume that you've distributed the full key pair to both parties you may even get away with using the same key pair as the padding would protect you against most if not all attacks.
Using RSA in ECB/OAEP mode of course has huge drawbacks with regards to performance, key management and overhead. It could also drain the secure random generator of the system. Furthermore, it seems that a symmetric cipher like AES is a whole lot more going for it with regards to security. So you'd probably downgrade your security level rather than upgrading it.
So yes, ECB is kind-of possible. If it wasn't you should not be able to encrypt multiple messages. Anybody implementing such a scheme would be considered out of hens mind by the cryptographic community though - and rightly so.
In the comments you further explain that
... but the idea is to use it similarly to how we use block ciphers today, as to avoid #1.
This would be impossible. Raw / textbook RSA is horribly insecure. You'd have to perform padding. Using the cipher in block mode of operation doesn't work. Furthermore, there is a problem with the highest bit of the input. With RSA you can deterministically encrypt something of size
N - 1.
N - 1 will not be on a bit boundary. That means that you'll always have a single bit of overhead. So even if it was possible to create a secure mode, you still could not use it as drop-in replacement.
ECB mode for textbook RSA is often used in textbook examples of RSA encryption with very small primes. After all of the above I hope I don't have to explain how horribly insecure that mode is; it breaks not just one but all of the rules.