Unfortunately, probably not.
The core of the problem is the fact that lips aren't just a solid two-tone color. There is a gradient, a blend, between the skin-color and the lip-color. That causes problems with the material system that DazV5-5 uses to minimize memory usage, which allows for more characters on-scene at a time.
DazV5-5 characters all have the same exact base skintone in the textures, and then their individual skintones are set by using materials to tint that base skintone. So for example, the Witcher ladies have a lot of a red tint to their skin, Rebecca Chambers has a gray tint, and Samantha Traynor has a dark orange tint. This by itself is perfectly fine, there's no problem with this system in itself, because tinting the textures as a whole has all of the individual components tint with them, which generally trends correctly with human anatomy.
The problem comes in with attempting to manually adjust the color of specific regions of the texture. The most common regions to want to recolor would be the genitals, nipples, and lips. The traditional way to recolor regions of textures is with what is known as a color mask. If you've ever painted a house, and you used painter's tape to mask off a window trim before painting the wall, then you know exactly what masking is - in fact, painter's tape is also known as masking tape, which is where the term "color masking" comes from. It's marking off specific regions of a texture to not be affected by a recoloring.
There are two traditional approaches to color masking in 3d engines: RGB masking, and alpha masking. Or if you prefer, three-channel and one-channel masking. In three-channel masking, a separate mask texture is used that is colored in solid shades of red, green, and blue. To make this explanation easier, let's call these channels one, two, and three respectively.
When the material is tinting the target texture, it loads in that mask texture and then targets a specific channel. So for example, the material could tint only what is masked by channel one to be purple. This means that what was painted red in the mask texture correlates to what is now purple in the final tinted texture. Then the material could tint what is masked by channel two to be yellow - meaning what is green in the mask texture becomes yellow in the final tinted texture.
Most games you see with easily swappable color palettes, such as character or gun skins, uses this system. It's a quick and easy way to get up to 3 different color schemes on a single model.
The alternative to RGB masking is alpha masking. Unlike RGB masking, this does NOT require an additional texture, and as such it takes up less filesize and less memory, instead loading the mask data into the alpha channel of the texture - which is always loaded regardless. This means you get a color mask basically for free. The problem is that there is only one alpha channel, meaning you only get one channel of masking. Or, in other words, you can only set a single tint across a texture - everything else doesn't get tinted at all.
When Valve made Source, they explicitly designed it to be able to run on a slightly moldy potato, and so minimizing memory-use and file-size was paramount to them. As such, Source uses alpha masking, instead of RGB masking.
Now, take the knowledge that Source only allows masking a single tinting channel in mind, and combine it with the fact that DazV5-5 models use tinting to set character skintones. I think you can immediately see the problem. I can ignore the mask and color both the skin and the lips, which is what I currently do. Or I can use the mask and color only the skin, leaving the lips their default pale skin-tone. Or I can use the mask and color only the lips, leaving the skin their default pale skin-tone. I cannot use masks to color both the skin and the lips - that would require two channels of masking, which Source does not support.
SO the solution I attempted was a hacky workaround. I created a duplicate of the lips mesh, pushed it ever so slightly in front of the lips, and then gave them a unique material. This material was an exact copy of the face texture behind it, with one exception: everything that wasn't the lips was transparent, with a smooth gradient between the lips and the skin. The end result is a transparent overlay that draws only the lips, overtop the existing lips. This new lips material then can be tinted arbitrarily, and because it doesn't need to mask anything - it's only the lips and nothing else, after all - it doesn't need to worry about masking channels, or affecting anything other than just the lips. The end user could then just tint or even swap out this custom lip texture as they saw fit, to get any color and pattern they wanted. A trivial example of this would be Kasumi Goto's lips, where she has those two purple bars on her bottom lip - that could be a custom texture, quickly installed onto this overlay, to get the effect.
To avoid any potential weirdness, such as the texture of the custom lips being smaller than the lips behind them, I painted over the base lips with skin color. So if the custom lip overlay was disabled, the character would have no lips at all.
The PROBLEM with this solution is, uhh, highly technical. And if you had trouble following everything I just explained, there's no hope in following the details of the problem. To keep things simple, I will just say that computers are really bad at decimal numbers, and they tend to "snap" decimal numbers together. So for example, while you and I can see the numbers "0.001" and "0.003" and clearly say that the latter is bigger, computers will just round both of these to "0.002" and say they're exactly the same. When I say computers are bad with decimals, this is the sort of thing I mean.
Recall how I said that the transparent lips overlay is very slightly in front of the actual lips. Well, that "very slightly" means "decimals". And computers are bad at decimals, meaning that when the camera is far enough away, it would just round the lip overlay positions to be exactly on top of the actual lip. And when you have two meshes that are exactly on top of each other, the computer doesn't know which to draw first, and so it constantly jumps between them, resulting in flickering. This is commonly known as "depth-fighting" or "z-fighting", because the mechanism used by computers to determine what to draw first is often called a "z-depth buffer".
So, that is why Elizabeth's customizable lips flickered. I used a hacky workaround that was bested by the fact computers are bad at decimals.
And unfortunately, that also means they will probably never come back. I experimented with a few solutions around this issue, such as pushing the customizable lips overlay further away from the actual lips when the camera was far apart, but they had to be pushed so far away to avoid clipping at even just waist-up shots that you could visibly see that the lips were floating and it looked really bad.
I like to think that I'm pretty handy when it comes to working around technical limitations. I've sort of made it a career of sorts, with the myriad tools I've written for my various toolsets. But alas, some limitations just can't be worked around. And I think this is one of them.