I would advise against Livestatus, since this feature isn’t actively developed anymore and a topic of deprecation discussions. Instead, rely on the backend of Icinga Web 2 (currently IDO DB, later Icinga DB) as the only true data source.
In terms of clients creating configuration, you’ll still need to have a central master which knows about this - and which can control (allow/deny) such configuration pushes. When the Director is used, you can do so with the Self-Service-API for instance. Or you’ll go with automation tools such as Puppet or Ansible, where the client facts are registered and turned into monitoring objects based on specific rules.
Putting the Director on a satellite only works for that specific zone, and from the many setups I know, this will run into problems. Our recommendation is to put the Director on the central master instance, and let deployments happen from there. If you’re not using the aforementioned Self-Service-API, you can also opt for using its REST API with creation of objects, apply rules, etc.
Cheers,
Michael