There's a some question marks that need to be answered to be better positioned to answer you.
The SEPM itself is only the server portion of SEP. In previous versions (SAV), the server was also the antivirus protection itself, but it has been seperated out...so now it's possible to have the SEPM installed without AV protection on a machine (although it's not a good idea, for obvious reasons). Where, exactly, are you seeing the reports of an infection? Are you viewing a report in the SEPM? Are you getting a pop-up on the suspected machine?
As for why the SEPM saw it and the SEP client missed it...we need to know how/where it was found. Again, the SEPM itself has no detection technologies itself...so if you're seeing it in a report from the SEPM, it means a client has found it and reported it up. It could also be from an installed client on the SEPM itself...but we need to know where it was found.
As far as the common names, sadly, I doubt that's ever going to change. Each AV vendor can name the threats however they want...there's no common naming convention or scheme. While it'd certainly be nice to see from both an end-user and support level, getting all of the AV vendors to use a common name for a threat truthfully probably won't happen.
The detection itself may not truly be infected, as this seems to be renamed from a generic packager detection.
Packagers are ways to combine files into an easy to distribute single file. A zip file is an example of what a packager does...combines a bunch of files and compresses it into a single file for distribution. Zip, RAR, ACE, GZ, TAR...these are all examples of what a packager does.
There are *tons* of packagers out there for people to use, each with their own pluses and minuses. Generally speaking, however, there are only a small handful of packagers that are used by most of the software vendors, both open and closed source. This leaves a ton of unused packagers for threat writers to choose from.
AutoProtect doesn't scan within compressed files. A packaged file is a compressed file...so, we don't scan within it. We do this to help limit the amount of resources AutoProtect uses to scan with...and it's my understanding that most of our competitors do this as well. The thought behind not scanning within compressed files is that if a compressed file containing a threat is on the box, it's okay, because as soon as something tries expanding that threat file from within the compressed file, AutoProtect will scan the "new" file, see it as viral and flag it.
AutoProtect *does* scan the compressed file itself, just not the contents. Think of mailing a package...the person you hand the package to at the post office gives it a cursory glance to make sure everything looks okay, but they don't open it to make sure it doesn't contain something it shouldn't. Later down the line it gets X-Ray'ed for just such a detection.
(Not a perfect analogy, but hopefully it helps to clarify)
So, back to packagers. We get a lot of submissions, and we look at a lot of files, both infected and not. We recognized, early on, that 99.9% of the files we saw packaged with the "other" packagers were viral. Once in a blue moon we'd find one that was completely legitimate, but most of the time they were viral. As we looked closer and closer at the packagers, we found that it seemed like it was mostly the people that use these obscure packagers were people packaging threats to try to get past our scanners.
There was a business decision made at some level to flag these "other" packagers as viral. All in all, we've gotten very few false positives as a result, and we've caught all sorts of threats trying to get into systems.
I'd recommend that you submit the file(s) for inspection. This may not even really be an infection...but I wouldn't do anything rash like exclude the files or anything quite yet.