Vague and ambiguous use cases
Thanks for all the feedback. I guess I should point out that the concrete, tangible use cases I've described do make sense (at least to me!) in the context of the overall development process that we described in the "Use Case Driven" book (i.e. the "ICONIX Process").
The reasons it makes sense are that:
a) the team will be working from a higher-level set of functional requirements ("the system shall..."), and the purpose of the use cases is to create a more grounded specification, i.e. it's time to nail down the specifics;
b) in the process of writing the concrete use cases, you would also be delving into preliminary design; so the developers would definitely be involved at that stage. So for example, they would have plenty of opportunity to say "hang on, the system just wouldn't assign an ID there, it would be part of an overall transaction" so the preliminary design, and therefore the use case scenarios, get a serious reality check before the detailed design work begins, and it gets everyone thinking about how (and whether) the system as specced is really going to work; and
c) the analysts can be assured that the developers fully understand the requirements, i.e. that everyone is "on the same page".