I suggest you started with a Character-base class, since it already has a proper movement component set up. For a Pawn class you’d need to create a movement component yourself, which gives you a restricted set of potential classes (some are not exposed for a strange reason, it will be getting better tough with upcoming versions).
But the movement component in a character works only with capsule collision mesh and as I remember this was the main reason why I did not use it.
You can still add a StaticMeshComponent to a character and have that collision as well. You can also scale down the original character capsule so that it doesn’t get in the way.
One thing you might need to change to make sure your custom static-mesh character works good with navigation is to properly set up its “navigation agent” properties. You do that by modifying properties of character’s CharacterMovement component in the Movement Component sections. Most importantly make sure you have Update Nav Agent with Owners Collision set to false and have all Agent * properties set up appropriately.
So if my units can change at runtime (static meshes might be added to them, creating sometimes irregular shapes) I would need to change the Agent properties after each change in my mesh, right?
Also are the agent properties just the bounds which my unit fits in?
Ok, I understand that now.
I have some issues with the character setup however. The very small capsule componenet, which I had to resize to half height -1 and radius -1 (only then the capsule was entirely in the static mesh), seems to cause problems with collision. Basically, the character falls through a platform static mesh (the collision for the platform is set up correctly). I need to use the collision mesh from my static mesh component not the capsule, but the collision from the capsule component’s child (the static mesh) is ignored even though it is set to BlockAll.
Agent properties really matter only if you plan on having more then one navmesh generated. If so these values are used to pick the right one for the agent. This is important since we generate navmesh for specific agents claiming if your agent is this given size or smaller it won’t run into obstacles with path generated on given navmesh.
You control what navmeshes are being generated via NavigationSystem.SupportedAgents (can be changed via the Project Settings).
If you have only one navmesh then you don’t have to update the nav agent props. But if your characters can “gain” size during game you’ll have hard time finding proper paths on navmesh. We don’t support arbitrary radius parhfinding yet.
Maybe try matching character’s capsule height your static mesh’s height?
I’m afraid your setup is too custom to be fully supported by the engine. Sorry!
I was prepared that a game like this will involve a huge number of workarounds and issues to fight with, so I am not discouraged 
As the capsule component cannot be translated, because it is a ROOT component, It would mean that the static mesh itself must be moved relative to the capsule (resized to match the static mesh dimensions) making the bottom of the static mesh below the character’s pivot point and thus every character would have to be slightly higher up, so that the mesh is not overlapping with the platform. This would make me change many algorithms I implemented previously, but that is a sacrifice I could make in aid of much more efficient and better navigation.
Thanks a lot for your help. Really appreciate it.