What happens is that the update system tries to enumerate the components of the entity while the entity is still being constructed. I'm using an entity-component system by the way.

This sounds to me like the real problem is that a reference to the entity under construction is available to other parts of your process before that entity is actually ready to be accessed.
I would recommend changing the entity creation to first create the object, not inserted to the world or visible to anything else, and then, once the object is fully created and configured, insert it into the world and make it visible to the rest of the process.

"Entity created" events can then come from the world itself, when an entity is inserted into it.

What about entity modification though? Suppose I want to add a component to an entity after it's already in the world.

The way I would solve that would be to not allow component add/remove while in the world; instead, I'd require you to remove the object from the world, re-configure components, and re-add it to the world.

Also, the "generate state dump for network update" and "add object to world" operations would probably use the same atomic unit (lock, or thread.) Just slurping the data out of the object is really lightweight, so putting that on the main thread wouldn't likely be a performance problem; any formatting and packetizing (and visibility management etc) could be done in another network-related thread if you want.

There'd still have to be an extra call at the end of creating the entity but at least forgetting that would just result in a useless entity rather than a crashing bug, so that's a plus.

You can easily remove the need for extra calls with a little function composition. In C++, you could write something like:

SpawnGameObject(blueprintName, [&](GameObject* obj)
{
  obj->SetPosition(4, 5);
  obj->GetComponent("a")->SetFoo(1);
  obj->GetComponent("b")->SetFoo(2);
});

So the function you pass in does all the post-creation pre-replication configuration work. The implementation is super simple:

void SpawnGameObject(std::string parent, std::function<void(GameObject*)> configure) {
  GameObject* object = CreateObject(parent);

  if (configure)
    configure(object);

  object->FinishInitialization();
}

You can use that pattern whenever you have chunks of code you need wrapped in other chunks of code. The RAII pattern also works but is clunkier for use cases like this.

What about entity modification though? Suppose I want to add a component to an entity after it's already in the world.

First, do you really need to do that? I've worked on several big component-based games now that never had any use case for adding/removing components at runtime, and most engines I'm familiar with don't even allow it. For many cases you can't enable/disable the component, add or remove message listeners, or register/deregister the component with external systems. The object component structure itself stays unchanged.

Second, you can make the network layer resistant to object structure changing. There are a billion articles online about concurrency-safe data structures, including a concurrent arrays. I don't think you need or want this, though.

What I usually do is have the network thread collect update requests from the logic thread (so the logic thread can decide when to send updates when it's safe to do so) to send and receives update packets and just queues them up on the logic thread. This is important for gameplay, really, if you think about.

You only want to sent consistent snapshots of components over the network. E.g. if two component variables need to be in a particular combination, you don't want the network thread reading those variables right in the middle of you changing them. Position and rotation are good examples of these; you don't want to send half of a physics update! If instead your game logic is responsible for sending an event to the network thread with the updated variables only when it's ready, the component can be sure that both values are updated in sync before sending it over.

Likewise for receiving updates, you don't want incoming changes to be applied to objects in the middle of your logic. Physics is still a decent example - if the code just did some work with its current position but then gets a new position+rotation right before it uses the rotation, you're going to see wonky physics behavior. It's much better to be sure that the network thread is only telling the logic thread that updates are available and then letting the logic thread apply them when appropriate.

Generally, this is true for almost all threading. Just don't have multiple thread modify the same data, period. Don't have multiple threads read the same data unless it's constant/immutable. Make threads communicate over thread-safe message queues. This fundamental approach to threading is what makes working in highly-concurrent languages like Eiffel or Go so much easier, safer, and often even more performant than the willy-nilly threading seen in C and C++ apps.

Which C# environment are you using? The Microsoft CLR is very good, and if you capture a few variables per frame, there will be no measurable GC penalty for this -- it will never "stop and collect" for a long time.
If you're using Mono, well, I feel your pain :-)