is there an accepted standard working unit for ORD?

The resolution shouldn’t matter as long as you have sufficient for the required precision you need. For civil engineering 1000 per foot is sufficient and many people use 10000. I once heard of a DOT that went to 1000000 which caused problems. 

Sounds like you have discovered a situation where mismatched resolution between your dgn and the cell library from where the annotation is stored causes a problem. I would consider this a bug and you should report it. 

I don’t have any other advice except to say I have sometimes ran into similar difficulty. 

solids working area should be no more than 1 mile or you will see 3D models starting a to get ugly. This is not really a problem unless you have very large solids in a single element. Under the hood the SWA “shifts” as needed when making the solids.  In other words the SWA does not need to cover your entire design plane.  

The one area where the SWA has an effect for us civil designers is for utility lines. For example it is common to have water lines which are many miles long. Break the utility segments into 1 mile or shorter lengths or you will have ugly pipes. 

There is something about resolution and annotation. If we use our traditional working units for everything (seeds, dgnlibs, cells, etc.) many of the annotation previews are 10 times too big. For stationing, its just a really long alignment, but for profile and cross section, the grid frames are enormous and really hard to use. Chuck Lawson helped us create new priview dgn files to make them appear more like they are supposed to look, but you have to ignore some of the annotation text in the previews. In a curve date and linear annotations, the lengths are wrong by a factor of 10 but only in the preview. When used in a DGN, they are correct.

If we use resolutions that match the example workspace and preview DGN's, all of our text sizes are too small and our users would be lost. We are trying to change only the things in the ORD Workspace that are needed to move forward to lessen the learning curve. These text sizes go all the way back to what we did in IGDS. While there are few of us around from those days, the people who had that knowledge on to are still around, as ar the ones that that learned from them.

These issues reach into plain MicroStation too. If you try to use the table elements with Excel, the delivered working units work OK. But our traditional units create tables that need to be scaled up which is not a saved property, so a refresh from source resizes it to its original size and it must be rescaled again.

It's also possibly related to Scales and Units as defined in the .def files. We adopted settings that allow text to be defined using sizes in decimal feet which users could relate to the old LEROY sizes. a 0.1 is a 100, a 0.12 is a 120. These are the sizes that go out the window in the new units.

There is something about resolution and annotation. If we use our traditional working units for everything (seeds, dgnlibs, cells, etc.) many of the annotation previews are 10 times too big. For stationing, its just a really long alignment, but for profile and cross section, the grid frames are enormous and really hard to use. Chuck Lawson helped us create new priview dgn files to make them appear more like they are supposed to look, but you have to ignore some of the annotation text in the previews. In a curve date and linear annotations, the lengths are wrong by a factor of 10 but only in the preview. When used in a DGN, they are correct.

If we use resolutions that match the example workspace and preview DGN's, all of our text sizes are too small and our users would be lost. We are trying to change only the things in the ORD Workspace that are needed to move forward to lessen the learning curve. These text sizes go all the way back to what we did in IGDS. While there are few of us around from those days, the people who had that knowledge on to are still around, as ar the ones that that learned from them.

These issues reach into plain MicroStation too. If you try to use the table elements with Excel, the delivered working units work OK. But our traditional units create tables that need to be scaled up which is not a saved property, so a refresh from source resizes it to its original size and it must be rescaled again.

It's also possibly related to Scales and Units as defined in the .def files. We adopted settings that allow text to be defined using sizes in decimal feet which users could relate to the old LEROY sizes. a 0.1 is a 100, a 0.12 is a 120. These are the sizes that go out the window in the new units.