Grabbing hashed password from a database
Regarding your questions, yes, that looks fine to me.

XSS

When echoing user input - or really any variable data - you need to protect against XSS attacks. Otherwise, attackers can inject JavaScript code, which will then be executed in the context of the browser of the victim, leading to bypass of CSRF protection, cookie stealing, phishing, or injection of JavaScript keyloggers.

Specifically, these statements are vulnerable:

echo 'Invalid password for the username: ' . $user;
echo 'The username, ' . $user . ', does not exist! Please try again.';


You can defend against XSS by using htmlspecialchars($string, ENT_QUOTES, 'UTF-8'); when echoing data.

Nesting

Personally, I don't like these kinds of nested ifs. It's hard to see which if clause the different else statements close. With just two, it's still manageable, but when the code is extended, it will become very difficult to read. 

A different structure might look like this:

if($numberofrows &lt;= 0) { 
    // return false or echo and die
}

if (!password_verify($password, $hashedPassword)) {
    // return false or echo and die
}

// return true, or start session, redirect


Now, it's a lot clearer which error message results from which check.

Misc


it's good practice to regenerate the session id when the state of the session changes to prevent session fixation (not an issue with default php.ini, but with some settings it is an issue). Use session_regenerate_id(true); for this.
using relative URLs in the Location header violates current standards, so if you can, use absolute URLs.
your comments don't really add any clarity to the code, so I would just remove them.
in PHP, it is generally standard to put curly brackets of if/else statements on the same line.
do you really need the call to store_result? It doesn't seem necessary to me.
your spacing is not internally consistent (eg $stmt2 -&gt; close(), if().
I would either use print or echo, but not both for the same task.
as a security precaution, you should always die after a redirect as clients do not have to follow it, and thus code below the redirect can be executed as well. In this case, it doesn't matter because the redirect is for a successful login, but it's good practice.