For remote access, as others have said, simple lockouts and delays can work.
For passwords, what you have is a one-way hash. To validate the password, you re-hash it, and compare the two hashes. Having more than one simple password produce a valid match against a single hash is considered undesirable: it means the hash is weak, and has "collisions".
So it's lkely that you are interested in encrypted drives.
What you describe -- fake, "outer" drives filled with fake data protecting the encrypted "inner" drive -- is possible, and has been done in truecrypt (which sadly has since died).
The following is my own naive understanding, and some or all may be wrong. I never used this feature, but considered it interesting.
Truecrypt allowed you to specify a second password, which would unlock a "layer" of the encrypted drive (might've been limited to one outer container, I forget). This had clear problems; the outer drives were unaware of the inner ones, which were stored in the "empty space" of the encrypted outer drives. So changes in the outer ones could destroy the inner drives. Also, the datestamps on the inner drives were not automatically updated when you accessed the encrypted drive. So someone with access to your machine could tell when you'd last modified the encrypted drive's file, and could compare those datestamps to the last-modified times on the encrypted drive, and immediately tell that you'd been using it more recently, so there must be an inner drive.
But the idea was, you have the outer drive have an easy-to-guess password, like password123, put some vaguely secret stuff in there, and that would make your opponents think they had got into your encrypted drive.
Anything less - anything which just returned garbage (random noise equivalent to an unformatted drive) would have been trivial to get around by checking for a "magic string" on the decrypted drive that would be required on any real drive but unlikely in a garbage drive.
Same with encrypted documents: most filetypes have magic strings, so if you know what filetype is contained, then any scrambling that's done can be brute-forced to find all ways that produce the magic string.
That doesn't mean it's a bad idea, though - if the magic string is, say, "jfif", then only about one in about 16 million passwords will result in that magic string. But if the key length is, say, 2^1024, then they've only reduced that to 2^1000 - which, sure, is certainly 16 million times faster to crack, but will still take literally forever to crack.
Casual password typos wouldn't make someone think they'd decrypted the file, but simply looking for the magic string wouldn't be enough.