I would try to use the noforward pragma and see if it works with types, since the manual is lacking information on forward declaration of types.
Not a direct answer to your problem but a workaround I've used in C is to declare all types/enums of the project in a single types.h file. Just like in C in nimrod you don't need to put the implementation of procs along with their type definition. And for procs you can forward declare them just by writing them again without the body. So you could define all your objects inside a project_types.nim module and then import that from everywhere else.
Not pretty, but maybe helps you get going.
Module systems don't deal well with cyclic dependencies. Often the only workaround is to declare all of your type graph in a separate types.nim module.
However, there have been studies that this enforcement actually improves modularity in practice: http://fsharpforfunandprofit.com/posts/cycles-and-modularity-in-the-wild/
Well you do have to make lots of things in types.nim public, but the clients should not import types.nim but instead the relevant symbols can be forwarded via export:
# private/types.nim
type
A* = ...
B* = ...
# public/package.nim:
import types
export types.A
proc p*(x: A)