It is hard to tell the true complexity of the model from a diagram count. We fixed some issues last year with very large files (5-10MB on disk) with repeated identification patterns causing major slowdowns. This was caused by over aggressive attempts to reduce the number of generated tables while analyzing the ORM model.
The core of the tool itself scales well beyond this size. However, there are a couple of areas in our use of the framework that cause lag in large files, especially on model load:
Sizes for all text-based shapes are verified on load, and all lines are recalculated on load. The line routing in particular is excessively slow because the framework ignores the parameter that says 'no jumps or bends' and calculates these anyway. I don't have an exact number, but this is the majority of the load time.
The relational view rebuilds itself on every major change, including the expensive rerouting of all lines. The relational model shows all of the information available in the relational view, so you can improve incremental performance by turning off this extension.
We currently do a full regeneration of the relationally mapped elements when any significant ORM change is made. On large models, this can easily result in transactions of tens of thousands of individual items. Work to get this incremental is scheduled for the first half of this year and will alleviate both the relational view issues and the sheer size of these transactions. Currently, even with models of the size you're describing, this adds at most a .5 second delay on an .orm model change, but we can definitely do better.
Bottom line, I think the scale of the models you're discussing will not have problems. Note that we're also using some internal partitioning tools that allow us to break up and selectively merge .orm files, generally without the shapes, which cause the load slowdowns. If you have major issues you can contact me off line on this issue as the tools here still require a fair amount of hand-holding (which is why they haven't been broadcast at this point),.