Filename encoding is defined by filesystem. NTFS uses UTF-16. It doesn't matter, though.
dir in command line it doesn't just copy bytes blindly. It first has to call appropriate OS function to list the directory, then print received file details to the console.
cmd calls the system function to retrieve directory listing, it already expects it to be returned in preferred encoding (which is not necessarily your encoding of choice - more on that later). It doesn't care what encoding is used internally in the FS, because OS provides additional abstraction layer to simplify things. FS can use any encoding you can imagine, but as long as OS supports it,
cmd will receive filenames in its preferred encoding, not FS's encoding.
The "preferred encoding" I've mentioned is either ANSI with codepage applied or Unicode. ANSI was used as default encoding prior to Windows 2000. Windows 2000 and newer versions use Unicode by default, but still can run ANSI programs.
For Unicode programs the codepage is ignored completely and
chcp has no effect. It's used only for older ANSI programs which rely on proper codepage being set. It doesn't matter anymore for Unicode, because it's well-defined and supports everything any reasonable program could output.
cmd does support Unicode, so it will receive filenames already in Unicode.
As you have already found out, the culprit was the default font. This problem is mentioned on Technet page on chcp:
Only the original equipment manufacturer (OEM) code page installed with Windows XP appears correctly in a command prompt window that uses Raster fonts. Other code pages appear correctly in full-screen mode or command prompt windows that use TrueType fonts.