A behaviour tree in robotics is in most cases used instead of an application program. It already assumes a running robot and a set of behaviours which are available at programming time.
I am not sure if ROS supports an application program based programming model, like industrial robots. If yes, the behaviour tree would represent the application program and would not include any steps, which are infrastructure relevant (like node config). But this is only through analogy with the current behaviour tree use-cases, not a technical limitation.
Other use-cases can be found for behaviour trees, so there is no rule on how granular a behaviour tree "has to be" or what it "has to do". For sure it could include configuration steps also, it might also make sense, the only limitation is that the entity interpreting/executing the behaviour tree instance has to support the defined behaviour. This is the only technical limitation.