Disclaimer: I work for Apiary
I don't think it's a good idea.
Your need for mock server hints at the fact that you've accepted the path of description-before-implementation, which is good.
However, the idea is that once developing against mock server, you iterate on the API design (that is one of the reasons why it makes sense to do it in "text" tools instead of code)...and that is the hard part.
There are some emerging tools that support scaffolding, but the real problem is how to update the scaffolded app after the blueprint has been updated. I know some people are tackling this, but they are not released yet.
In my opinion, the best approach is to develop real prototype against the mocked API to test the UX of the resulting app. Once the design is reasonably stable, you start developing other clients as well as server, eventually extending the original design.
You test them with respective tools found in the respective languages as their are best for given use case. To test that implementation conforms to blueprint (aka written contract), you can use dredd.
Any tool that cooperates on top of that should take blueprint as an input instead of generating the library to extend manually that is impossible to maintain.
