Is there an interface that is built in by Microsoft that people seem to not know about?
There doesn't need to be a special interface. Loading of dynamically-linked executables on Linux is done by userspace libraries (e.g. when you run an ELF file, it usually indicates
/lib/ld-linux.so.2 as its "interpreter"), with libc – not the kernel – being what actually handles the loading of .so files both on startup and later via dlopen().
This means that any program can implement its own executable or library loader, if it really wants to – the kernel's involvement is mostly in the generic syscalls to mmap the file into memory and mark the right memory areas as "executable" (mprotect) when the loader asks. (For example, this user-space loader was posted to replace removed kernel support for the old "a.out" format.)
As another example: Wine, a distinctly non-Microsoft project, has also had its own support for loading PE-format Windows executables (and allowing them to load PE-format DLLs) for much longer than PowerShell has existed. (Previously Wine's own .dll's still used to be ELF inside, but recently it has switched them fully to PE as well.)
So with that in mind:
How is it that Microsoft Powershell is able to install DLL files when installing onto a Linux machine and still work?
PowerShell as a whole is built on the .NET runtime, which has always used PE/COFF even on non-Windows platforms – the .NET runtime has its own PE loader (much like Wine does) and is what handles the .dll file format overall as well as the CLR bytecode found within.
(Also, even though those are PE files, they aren't ordinary "Windows" DLLs – remember that .NET languages weren't originally compiled directly to machine code, it's a bytecode platform similar to Java.)
In the case of .NET, most of the DLLs in question do not make OS-specific calls directly – they stay within the .NET "world" and the runtime itself provides the abstraction layer. (It's possible for .NET code to directly make calls to external libraries though, and those would indeed fail on the wrong OS.)
In earlier days even the main executable used to be a PE-format
.exe file regardless of platform. For example, if you installed the Banshee music player in GNOME – a fully Linux-native app written in C#.NET – you would actually have /usr/lib/Banshee.exe, a PE32 executable, running through the Mono runtime.
(Banshee had a wrapper script in /usr/bin to launch it, but Linux does also have the "binfmt-misc" facility that allows the execution of non-ELF binaries to be transparently delegated to an interpreter – it's easy to declare either Mono or Wine as the handler for
MZ PE files.)