There isn't anything available from Progress that I'm aware of. You could look on the internet for naming conventions for DB (tables, fields, indexes, sequences), variables, classes, methods, properties, etc. It wouldn't necessarily have to be OpenEdge-specific to be useful. Probably something based on any DB or OO language could provide a decent starting point. Make sure your DB designers are at least familiar with generic concepts like normalization and the normal forms. They should have an idea of what the are, which they want to adhere to, and hold themselves accountable to that. If they are designing indexes they need to understand how the query engines work (4GL and SQL) and in particular how the rules-based 4GL engine selects indexes and brackets on them. That subject is very poorly understood, in general. Another point: don't just create a database schema and expect people to understand the intent behind it. You should start by using a third-party tool (as Progress doesn't provide any) to create a data model, complete with the necessary descriptions of the objects and their purposes, and the relations between them. Then create your schema from that. If you maintain the discipline to keep doing that you'll be ahead of a lot of folks.
In some ways conventions are a matter of taste. One person's perfect naming scheme could make another person recoil in horror. I guess if any one system could please everyone then there would only be one system, and that's not the case. I will say though that having (almost) any naming convention is better than having none at all; having been in both situations I can say that from experience.
You should also be aware that, as Tom has said, just because OpenEdge lets you do something that isn't a good enough reason to do it. You can store gigabytes of XML documents or images, that you might never query, in CLOB or BLOB columns in your database. You can create array fields. You can put validation logic in the schema. You can use ACCUMULATE statements. You can use OF syntax for joins. That doesn't mean you should. Also, be aware of the lists of deprecated and de-supported features in the Product Availability Guide. Don't introduce new code with old features that someone will soon have to fix or refactor.
Regarding NO-UNDO, you should declare all variables, temp-tables, and parameters as NO-UNDO unless you have a good reason for doing otherwise. If you do have a good reason, add a comment to the code so that the next developer doesn't just think you omitted it by mistake.
There's a lot that could be said about conventions for both DB design and ABL code but that's a start.