Why can’t Safari display this emoji when I am logged in

That looks like the front-end processor window for some non-Roman scripts. This gets pretty far into the weeds if you don't normally use them, but in case you're curious:

With a writing system like Japanese, you type using English characters to produce phonetic Japanese characters, and then convert those into ideograms. For the most part, this happens "inline", that is, right where the cursor is, wherever you'd be typing if you were typing in English. Back in the old days, however, it happened in a separate window (the FEP window), and once you had a chunk of text composed in that, you'd send it to the main window.

I use Japanese on my system. The FEP window still exists, and every once in a while it will pop up for a second—then the system seems to get its composure back and I go back to inline typing. I'm guessing that you're trying to produce a character that involves multiple keystrokes, like ü, and somehow that's invoking the FEP window. I can't say why it's happening or how to stop it, but in my experience it is harmless.

The difference is the rendering engines for the browser windows.

We know Safari renders the character set differently than Chrome. But the Window UI elements (the tabs in Chrome) are okay. That's our biggest clue.

The window UI elements are likely (emphasis on likely, I may not be correct here) all being rendered by the OS. So they get the full OS-level emoji-expansion treatment.

But what happens inside a web browser window is all very browser dependent. The rendering engines are a big part of each browser's secret sauce.

Both Safari and Chrome use WebKit, but the similarities between the WebKit instances they use stop somewhere around the name of the engine. They're both forks from the main version and they're both heavily customized to improve the performance in ways that each browser development team thinks is meaningful for their end users.

@JasonSalaz found a great bug in the Chrome bug database that gives us the final clue that it's down to WebKit forks: http://code.google.com/p/chromium/issues/detail?id=90177 -- that bug is talking about the differences between the fork in Chrome and the mainline of WebKit from the open source project. There are rendering differences in the mainline that have yet to make it in to the version Chrome is using. And it looks like they intend to merge the changes in at some point.

Update: Paul Irish has a great blog post on how WebKit differs for all these browsers that currently use it. If you really want to understand just how diverse the WebKit environment is, this is a great read.