The first two rules of REST are that everything is a resource and the only verbs you should be thinking about are the ones that HTTP specifies.
I'll go out on a limb and assume that you have a model where access to identities starts at
/identities and that you can pull one out by ID with
GET /identities/1234. I'm also going to assume that your API outputs JSON and the
http://host/ at the beginning of any URIs is implied for brevity's sake.
Theoretically, you could
GET /identities and get back an array containing references to every identity in the system:
[ "/identities/1234", "/identities/5678", "/identities/9012", ... ]
That's probably not what you want, but you can allow it in small doses using query strings to limit the list to a subset.
GET /email@example.com would be an ideal filter for checking whether an email address exists because your business rules say they have to be unique. That means the returned array would always be zero or one elements:
[ "identities/1234" ]
Another way to go about this is to build the filtering into the model, where there are multiple paths to the same resource:
Trying to retrieve the second resource would return
200 if an identifier with an email address of
firstname.lastname@example.org existed and
404 if it didn't. While having multiple paths to the same resource is considered acceptable in REST interfaces, you'll need to consider whether that presents any logical problems like not knowing if two non-identical URIs point to the same resource.