Yes; this is a problem with negative requirements statements. Just like you can't decrement a forward iterator, you can't dereference a singular iterator.
The characterization "just like" is a little off. Trying to decrement a forward iterator is a conceptual error. Trying to dereference an iterator with a singular value is a logic error. I think we get into trouble when we talk about "valid iterators". I don't think there's such really such a thing at all. There may be cases where it's valid to decrement an iterator, but not dereference it. There may be cases where it's valid to dereference an iterator but not decrement. A PTE iterator is well-formed, but both incrementing and dereferencing is invalid.
The point is that the OP claimed every default-constructed iterator is singular. The only way that could be true is if you take the term "is-a" in the sense I'm using it here. That is, I can easily create an iterator that, when default-constructed, supports a strict superset of the required operations for singular iterators.
Without any strong guarantees about the state of default constructed iterators in general, I don't think I'd try to use them in a generic algorithm. This is just begging for trouble: template<typename I> auto f() { I i; assert(*i); } // worst algorithm ever If I know that the iterator has valid operations after being default constructed, then I'll do as I like -- whatever the concept does or does not say. counting_iterator<int> i(0); cout << *i <<; // should work just fine