Is there a standard way to indicate that a function returns a new pointer?

Return a unique_ptr:

std::unique_ptr<Vertex> new_vertex(const Options& options) { // do stuff... return std::make_unique<Vertex>(...); } 

There can only ever be one unique_ptr pointing to a given object (unless you abuse it by casting to a Vertex* and back, anyway). You can't ever copy a unique_ptr, only move it. When a unique_ptr is destroyed (and hasn't been moved out of) it even deletes the object for you.

make_unique creates a new Vertex and wraps it in a unique_ptr; the arguments you pass to make_unique are the arguments it passes to the constructor.

Is there a standard way to indicate that a function returns a new pointer?

No, there is no "standard way" (but there is an API design policy currently considered "best practice").

Because of this ambiguity ("what does a function returning a pointer want me to do with it?"), it is currently considered best practice to impose the lifetime and ownership policy, through the return type:

<vertex pointer type> new_vertex(const Options& options); 

<vertex pointer type> can be std::unique_ptr ("new_vertex doesn't own the pointer"), or std::shared_ptr ("client code doesn't own the pointer"), or something else, that has clearly defined ownership semantics (for example, Vertex const * const would indicate to client code "read the address and values, but change neither/don't delete the pointer").

Generally, you should not return a raw pointer (but in some cases, "practicality beats purity").

TLDR: there is a best practice (yes), but not a standard way (in the language).

Edit:

where the function is only intended to be used to within a class that owns the Vertex

If the class owns the Vertex, I would write it like this:

class SomeClass // owns the vertex { void do_stuff() // uses the vertex internally { init_vertex(); // see below assert(vertex.get()); // use vertex as needed } private: // "class owns the Vertex" std::unique_ptr<Vertex> vertex; // sets the internal vertex // function doesn't return a pointer of any kind void init_vertex(const Options& options); // or "reset_", "refresh_", // or "make_" vertex, // if the pointer can change // throughout the lifetime // of a SomeClass instance }; 

Yes, there are dozens of "standards" about this

The answer recommending unique_ptr is probably the best answer, but if you're looking at raw pointers, everyone's developed their own standard.

Generally speaking functions named create_____ or new______ or alloc_____ tend to imply a new object.

However

Consider that you're mixing behaviors. You don't actually care whether this is a new instance of an object or not. What you care about is whether the caller is responsible for destroying the object or not. There are many APIs which hand over the responsibility for an existing object, and those functions will need a matching naming scheme. Perhaps give______.

If you're willing to step a little away from C++...
If you're willing to consider Objective-C to be similar enough to C++ to be a source for an answer, there's actually a real answer in that language. Objective-C manages the lifespan of objects using reference counts. They needed a way to describe whether you were being given responsibility for an object, or merely a reference to an existing object. If you get the answer wrong, you get the ref-counts wrong and lose objects. Accordingly they made a rule: every object you are returned is owned by someone else (so you must increment and decrement the ref count yourself), except for creation calls which pass an already incremented pointer to you (you only have to decrement). These calls were identified by the method name. Methods starting with alloc new copy or mutableCopy always returned a new object. So there, the standard was enforced by the language.