None of the things you desire are natively available in Neo4j (to my liking I must add). It is up to the application developer to come up with a schema/namespace or entirely do without it (which is perfectly fine for a simple data store).
I can tell you a little bit about the approach we have taken creating
multispective.com, a CMS running on top of Neo4j.
The core module of multispective is essentially a wrapper around the Neo4j database, so the application has no knowledge of the underlying datastore. This wrapper allows for the lookup of data by type instead of by name and unifies the various data store entities.
In our core module everything is considered a vertex, whether we talk about Nodes, Relationhips, Properties, or RelationshipTypes. This not only simplifies the API, it also allows for relationships to relationships and relationships and properties on properties.The most compelling reason for this unification lies in the composability of traversals (on which more later, if I don't forget).
Every vertex has exactly one type, classified as VertexType (for nodes), PropertyType (for properties) and BinaryEdgeType (for relationships).
All these types can have many subtypes and many supertypes.
PropertyTypes are further classified per datatype, so it become possible to get an exact datatype (instead of java.lang.Object) back when asking for a property value.
BinaryEdgeTypes are further classified by arity, so we can state whether relationship is OneToOne, OneToMany, OneToOptional, ManyToOne etc...
The contraints are guarded so that no vertex can be created without a mandatory relationship or a relationship is created with an arity higher than the one given.
Types furthermore add basic information as labels, description, size (in case of variable length properties, such as String, BigInt, BigDecimal) etc.
Types as maintained in namespaces. Each domain has its own namespace, defining their own types, while additionally importing types from other domains.
This particular set-up works really nicely for a multi-tenant content management system (where different namespaces are required), although I can imagine other solutions for other use-cases.
Niels