Viewing Special Characters
The good news is that this part should almost always 'just work' on OS X and iOS devices. Encodings are usually handled intelligently, Unicode fonts are installed, and font substitution does its job.
If you do encounter problems, be sure to specify the encoding as Unicode (UTF-8) when saving. If your text editor doesn't allow you to specify an encoding, it's a fairly safe bet that this is what it's using.
Since Markdown files are plaintext, you don't have to worry about fonts. If you are using rich formatting, though, Lucida Grande, Arial Unicode, and Apple Symbol are all good options. But, again, OS X and iOS generally switch to another font seamlessly when the main font doesn't support a character.
Entering Special Characters
Both OS X and iOS include built-in text replacement tools that will let you insert your symbols easily.
OS X
Open System Preferences-> Language and Text-> Text and click the [+] button. Choose a keyword to be expanded and paste in the special character. You'll have to create snippets with unique keywords for each character.
iOS
Copy a special character. Open Settings-> General-> Keyboard-> Shortcuts and tap the [+] button. Paste the character under Phrase and enter a unique keyword under Shortcut. Tap save. Again, you'll have to create snippets with unique keywords for each character.
If you like, you can use the excellent TextExpander to do the same thing, but it isn't necessary in this case.
I can see that this is likely to be very restrictive until you find a solution, so I offer this workaround to ease things while other answers come in. If you enter your password into your username field, then select it, copy it, and type over the top with your actual user name, you can then paste the password into the password field.. This is 3 extra taps overall, but will at least allow you to use your logins in the meantime.
Best Answer
This problem come from the order in which 2 important operations are scheduled to read a sensitive piece of information which is a password:
Apparently these 2 operations are scheduled the wrong way round:
The part of the kernel in charge of reading the keyboard is waken up before locking the keyboard. This is fully understandable when you want to be able to wake the system on any keyboard entry. But in such a case, a mechanism should clearly indicate to the user when the keyboard is safe to type a serious password and not wake up noise.
This wrong scheduling was apparently a small problem and not noticed by many users since the 2 operations are anyway scheduled in a small window of events (it's a question of one or 2 seconds here).
This small window of time to schedule these 2 operations is larger if you are just waking up your disk, or if your disk isn't fast enough for your fingers, or if you have too fast fingers. This is the reason why some people thought that this problem was created by hard disk drive (HDD) and suppressed by solid state drive (SSD). In fact the problem isn't suppressed by an SSD, it is just more difficult to exhibit. You should consider this as a fundamental bug in password reading which is hidden when using a fast enough disk or slow motion fingers.