Unfortunately, due to the way NeoLemmix Editor handles styles, it's almost impossible to do that. The images of pieces are decoded when compiling the styles; therefore, they're already in correct (unaltered) colors. The traditional Lemmix editor was able to do this because standard graphic sets and VGASPECs weren't independant; a specific style option would refer not to one graphic set or one VGASPEC, but to a specific combination of a graphic set and a VGASPEC (yeah, of course you could have a graphic set without a VGASPEC, but in a way this is still a specific combination - the graphic set + no vgaspec; not like with NeoLemmix Editor where you can then choose a VGASPEC seperately); therefore when compiling, it could apply the VGASPEC palette. Because the two are independant in the NeoLemmix editor, this same approach would not work. I would like at some point to eliminate the need for compiling the styles altogether; once that's done, this feature may be more likely to be implementable.
Indeed, even in NeoLemEdit, the way this was implemented was by literally re-loading the style using the altered palette when the VGASPEC was changed. On the other hand, the NeoLemmix player checks for a VGASPEC (and changes the palette accordingly) before it even loads the standard graphic set, which is why it can be altered without problems there.
The Martian style won't be affected by any VGASPEC because its palette is specifically constructed to not be affected. This should even apply to the terrain pieces too. None of the other styles are constructed as such, so all others will most likely be affected.
I'll look into that memory leak. I know that error itself happens when switching to a style that results in the level having an object that doesn't exist (for example, create a Metal level containing a splitter (the last object in the style), then switch to a style that has empty object slots); improving the handling of this is on my todo list.
Here's a shot of the Lab style, with Nyancat VGASPEC, including some terrain.
Notice how some colors are unaffected - this is because a palette-based VGASPEC won't touch colors beyond #15.
I find in general, Lab goes very well with a lot of VGASPECs - for example, aside from the window, most objects and terrain don't even look at all out-of-place in all the official VGASPECs (except Prima and Covox, but it does work nicely in the Sunsoft one) combined with Lab; even the window looks pretty good in the two Beast ones. It also goes quite nicely with Duck, Rickroll and RickrollII; not so well with Troll.