I used pretty much the same structure, however it was still a bit different. Since Page Object pattern is more about "page objects" rather than the pages as they are known by the most of the web users, there could be the objects which do not relate to any particular page. For example the fragments which might appear on every page (like footer or header sections) or "objects" which the user can "invoke" on quite a lot of the pages because of the design pattern reusage.
Thus I had the following structure under the
elements contains the objects representing the complex controls which are widely used on the UI,
common contains the areas which are common for all the pages, and
pages contain the "fragments" which have some specific functional value for a user.
The structure under
test was a bit different as well. Since I didn't want to accosiate the design pattern of the tests with the design pattern of the main code. I could afford this (without missing the common sense) also because my tests worked with the e2e user flows rather than single and atomic user actions like just "login" or so.