Had Apple properly validated the input and accounted for this case or disallowed it entirely they could have avoided this.
Don't mean to troll but there are two sides to every issue like this: blame the user or blame the developer.
Apple dropped the ball here by allowing a password to be set to something that could not be typed at the login screen.
The user was stupid for performing this experiment without an escape hatch.
Stating one does not exclude the other.
I don't backup my C:\ drive before I "experiment" with the cut & paste tool.
If you saw an emoji keyboard pop-up on your change password screen it would be natural to just assume that the OS was now accepting emojis in passwords.
"I wanted to check if it's possible to use emoji in a password for my Account on OS Yosemite."
You're correct in general, but in this particular case they clearly saw this as something that might not work. They just didn't anticipate how badly "not work" could go.
This is clearly an input validation issue first and foremost, and we can blame Apple for that, but it's also a completely weird use case and obviously a non-standard path to password input given you don't have emoji keys on keyboards.
I don't expect average end users to know that unicode support in software is still iffy, but I would expect them to realize that having to bring up an alternate input dialog is deviating from computing norms. Doing weird things should trigger a red flag in everyone's heads that "maybe I shouldn't try this first on something I value". Doesn't even matter if it's a computer, you wouldn't try refueling your primary car with wine, despite it containing a plausibly similar sounding percentage of ethanol.