I've been messing around with this to see if I could find a Javascript solution for this (and a number of other things I've been trying to find solutions for), and I keep hitting the same wall. 

This includes some guesswork, so if I'm wrong, hopefully someone will set me straight. 

With the classic designer, the Javascript is part of the form itself, and thus we can have Javascript (or JQuery) code that functions on any part of the form, and even some other parts of the window outside of the form - we have a lot more control and customization - but also more risk of doing something weird.

With the new designer, as best I can tell, the custom Javascript we are adding are running within an iFrame, so it is effectively an entirely separate website.  And the origin of that iFrame appears to be different than the origin of the main page, so you get cross-origin errors if you try to do something via window.parent.  If I'm right, that is why you can't get any code to work that manipulates fields, their components, or the structure of the form itself - they are just not inside the same frame at all - effectively, not on the same page.  With the form structured this way, any access to components of the form is entirely limited to what exists in the LFForm object which passes the commands over to the main form in the main window.  But if the desired functionality doesn't exist in the LFForms object, we can't handle it more directly with Javascript (at least that I can find).

I'm sure from a security perspective, this is much better.  But from trying to extend functionality with custom code, it's kind of cut us off at the knees.  This is the biggest hurdle for me with the new designer, because if I can't do something with built-in functionality, I always find a way to code it, but that option has been severely limited.

So, bottom-line, I don't think it's possible to do this with the new designer currently.