Let's say I have my own implementation of std::vector, which provides begin() and end() functions for iterations. It may happen that size()==capacity() and pointer returned by end() is not owned by me. Will it be safe or do I need to ensure that size() < capacity()?
I know this dilemma can be overcome by using custom iterator classes, but here I am talking about the simpler case when begin() simply returns a pointer to the start of buffer, and end() to the begin()+size().
The standard prohibits dereferencing an invalid pointer (and the standard goes a great length describing what may invalidate a pointer, for example the life-time of the pointee, life-time of the memory chunk itself and the alignment of the pointer).
One can hold an invalid pointer as long as the user of that pointer doesn't dereference it, and in some cases as long as the user of that pointer doesn't read it (see comment section).
as you suggested yourself, end is simply return begin() + size()
A T* value is valid if it points to a T (which may be a sub-object of an array) or if it points one-beyond-the-end of a T[]. All other values are invalid, and using such a value is undefined behaviour.
This means you can compare (<, ==, etc) valid pointers, but not invalid pointers.
A T* value is dereferenceable if it points to a T. Dereferencing an invalid pointer, or a one-beyond-the-end pointer is undefined behaviour. This is a different set of values to valid pointers.
begin()+size() will give you a valid pointer, which is not dereferenceable.
Your first problem is that it isn't possible at this time to hand roll a standard compliant std vector. There is no way to create a buffer with room for K Ts of which the first N are in an array of Ts, then resize this to N+1 Ts without reallocating the first N.
This is due to the fact that a buffer containing N (or N+1) adjacent Ts is not an array of Ts, and pointer arithmetic on T*s won't work quite right (under the standard) within a mere buffer of adjacent Ts, the way it works with a real array of Ts.
This is because the standard limits how far you can do pointer arithmetic on a T* to be within the T or one after; even if the T lives in a packed struct or buffer. Such limitations restrict how "reachable" objects are; if you have a struct with 3 ints, no arithmetic on an int* could modify more than one, so certain caching can be assumed to work and the compiler doesn't have to go back to RAM each access.
The unitended side effect is that there is no way to legally implement std vector. This is a flaw imnthe standard, the comittee is aware of it, and I asume someone is fixing it (for all I know it is fixed in c++20, I don't think I missed the fix in c++17).
That being said, you can ignore all this, because most compilers get sufficiently confused by manual object construction in a contiguous buffer that their code to exploit the assimptions doesn't break your hand rolled vector.
Regardless, defined pointers values are those into an array, those one-past-the-end of an array, and individual objects can be treated as arrays of size 1 for this purpose. Pointers one-past-the-end exhibit UB if dereferenced even if an object exists there. Pointers in that range can be compared with < >= etc with each other (but not with pointers within/one-past other arrays). None will compare == to null, and all will compare != to null. != and == I believe work as you'd expect with them.
