New (soon to be) owner here coming from a long history of ST, Homeseer, and Vera devices. One of my pet peeves for all the hubs was there was no way to set a bulb's color (or color temperature, or brightness) without the bulb powering on. On the ST platform I took one project--if I recall Hue Groups...and modified the code such that brightness and color changes were saved in the device's data and applied when a power on was received. This worked great for an app called circadian rhythm which changed the bulbs color over time to mimic natural lighting. I also used RM to copy this behaviour too in a simpler way (it could spam all the lights with the new color and not turn on bulbs that are off). How do these commands (color and brightness) work in HE? If they behave like every other platform, hopefully I can come up with a solution as easy as I did in ST (literally it took 30 minutes).
It's quite possible that what you did in SmartThings will translate to Hubitat. Same Groovy.
Would be VERY interested in knowing the secret to this ability! 
It figures, I didn't save my code. All I did was have the device handler save the values and check to see if the bulb was on when a brightness or color command was received. If the bulb was on, it passed the command as it normally would. If off the values would be saved without sending a hub command (which appears to power on bulbs that were in an off state). Finally power on commands also sent brightness and color (or temperature) as well for cases where the bulb was off when they were received. It was easy and worked well in ST.
So I looked at the Hue B Smart code...very similar to what I used before so in theory should be really easy to do. For me, I preferred the setlevel (brightness) command to not power on the lights so I could easily manage bulb brightness without a complicated system of determining which bulbs are on and changing them. This way a bathroom light could be set to be dim at nighttime for example. I suppose this could break a few apps that either expect setlevel to turn bulbs on, or if non-zero brightness or level attributes were used to determine if a bulb is on. Hopefully I can have my hub by Monday so I can give it a try!
I'm hoping that this "code magic" might solve a problem I've been having with my hue/HE setup.
I have RM rules to set level and CT based on different times of day (location modes) and I find that using RM alone is having inconsistent results.
What I'm experiencing is that randomly the set level and set CT commands seem to be conflicting and causing the bulbs to not set correct level or CT. My theory is that HE is delivering the commands too fast causing the hue bridge or the bulbs themselves to get confused? As an experiment I've lowered the default transition time to 500ms and in my RM rules I have only the set level command with a virtual button controller setup to handle the CT with a 1 second delay so that the bulb has finished turning on before the CT is changed.
With the stock implementation I see the bulbs have a strange "strobe/flicker" when they turn on I'm assuming because the set level and set CT command both turn the light on. With my work-a-round it seems that this eliminates it and hopefully solves the random failure to set correct level/CT.
Your approach would be much better as it would allow the bulb's CT to be pre-set when the modes change and thus prevent the visual CT change after the light is ON.
@xap has already ported parts of hue b smart over to HE so maybe you can use some of his work as a starting point. Although I know a lot of the code was removed so you may need to start from scratch.
The wife hasn't been happy with how the lights have been turning on, and I am not a huge fan myself. We set the light output level per mode (time of day) when the lights come on after mode change they first come on to the previous mode's output level, and then transition to the new level afterwards. Okay, I was thinking I can fix the order of operation issue myself. I was going to create another rule that would update the new output level when a mode change occurs and the lights turn off. Effectively presetting the out level before the lights come back on. Tried doing this on single bulb in my office, no luck. As you have seen, changing the bulbs output level immediately immediately turns on the bulb.
I have seen a few other odd things. With HE/HueBulbs it appears I can only support Level 0 and 2 to 100. Not a level of 1. When I change the level to 1, the bulb reacts, but the current state always reflects the previous settings. I can only replicate this behavior when setting the bulb output level to 1. This applies to a single bulb or a bulb group created in Hue. See attached. Bulb was set to level 1, the bulb is at its lowest level, but the current state.level still at the previous setting of 100%
