The log-in credentials are processed in wp_signon(), and if they are valid wp_set_auth_cookie() will send a cookie in the HTTP response body.
The name of that cookie is set in a constant named SECURE_AUTH_COOKIE or AUTH_COOKIE. Both names start with wordpress_.
But they don’t have to. You can define these constants in your wp-config.php and add a layer of obscurity, so the attacker don’t know really sure if it is the regular cookie.
You could add another layer: hook into the action 'wp_login_failed' and send a cookie that actually starts with wordpress_. You could name it wordpress_logged_in for example. It doesn’t do anything, and will not make your blog measurable safer … but it doesn’t hurt.
On the other hand: WordPress will send a location header and redirect the user after the log-in to another page. That’s easy to detect and harder to circumvent.
An additional check I use on many sites now: Add a new checkbox to the login form per JavaScript with a unique name per site and require it to be checked. If it isn’t checked, the response will always be a blank page, even if the password is correct. You can get it from GitHub: T5 Unique Log-in Field.