Without going into the gory details: David is right. HISEScript is not suited for "real" object-oriented programming and as soon as your talking about making dynamic GUI elements you're quickly getting into hacky workarounds.
There is one design paradigm in HISEScript which will get in your way pretty quickly and that is that every UI element has to be declared on script initialisations. This has implications on the user preset system, plugin parameter automation, state saving etc. In C++ it is no problem creating other UI elements if you press a button, because you can easily decouple the data from the UI elements.
Moreover, there's an uncanny value where any scripting language becomes a burden, because you start relying on industry grade debugging tools, and even if HISEScript tries to push that a little further than other scripting languages (which is why I bothered with breakpoint, local variable watch etc.) at a certain point the efficiency compared to C++ goes towards zero.
Once you get past the Bjorn-don't-torture-me-with-<thisTemplateSyntax> state, C++ (and especially with the new C++11 / C++14 enhancements) will quickly become the language of your choice for anything audio-related - and KSP really starts to look like assembly from the 1980s :).
JUCE also does a marvellous job of nudging you into a good coding style, which is why I decided to open the C++ API in HISE.
I don't know you personally, but from what I've read from you in the past (here and on VI-Control) you should be able to grasp the basics of JUCE/C++ pretty quickly and leverage the full flexibility of true object orientated programming (plus being able to write C++ is a very valuable skill). The screenshot you posted is trivial to implement in C++ BTW.
On the other hand, I won't stop you from playing around and trying to push the limits of what's doable. The code you posted looks reasonable (and I must contradict David here and say "leave the interface designer alone for this kind of stuff or you will shuffle pixels around forever").