Hcfyk

It's a very bad idea to not show the link. You should always give the user the option, even if they are likely to try a few passwords first.

How about an example - what if you have a password manager, and your credentials for this site is somehow lost/missing from your password manager?

You have no idea what the password is, as it will likely be some random combination of letters, numbers, characters, etc., and therefore will want to reset it straight away.

Globally Consistent Convention Versus Design "Wants"

There is always weight towards convention in user experience/interface design for numerous reasons, but crucial systems where there is a safety/security element are ones where that should be given even higher than normal priority.

In my current project we need as much space as possible

Your reason for wanting to try breaking with a globally (externally) consistent pattern is essentially "we're lacking space".

Others have explained certain aspects of why this is a pattern you shouldn't break from specifically in relation to the element you're asking about. Those are great answers and this is merely meant to be a supplemental piece in addition to them. I want to address why you feel the need to break from convention in the first place and advise that you circle back to this encompassing design issue as the real reason you tried finding something to cut at all, and what therefor instead needs to be addressed.

Needs vs Wants

My simplest advice would be this: when dealing with anything related to security or safety, I recommend you consider conventional design components and layouts to be "needs" and your contravening design level issues to simply be "wants": if you can come up with a hard need related to the core purpose of the interface (for example: people are misclicking on a UI element and it is causing authentication issues), then it can be properly weighed against the various reasons already behind the conventional design needs (such as, if we move these elements to avoid misclicks, does it cause a worse issue to emerge that was already foreseen in the current design, making this a necessary evil), but until it arrives at that point it is merely a want and can generally be considered lower precedence.

Generally speaking, a login page/screen/modal should have as little extraneous information going on as possible, both for the sake of usability but also potentially for the sake of security (for example, avoid loading external resources where possible here). If you have a space issue on your login interface, something is almost certainly "wrong" with the encompassing design (even if this is an embedded interface of some kind). It's impossible to speculate about what per se the problem is without any related information, but I'd strongly urge you to stop trying to look for ways to break from convention here and instead look at how you can refactor the design of this interface to better fit with conventional login interface paradigms, even if it means that this screen does not perfectly match the design templating of other screens (I'd absolute advise that you keep at least related elements consistent: brand logos, colors, etc, but simply find ways to cull elements and/or reduce whitespace areas/etc that are not necessary for a login screen).

Login interfaces in particular have numerous usability concerns which overlap with security concerns, and breaking with conventional design--beyond the generalized usability reasons to try to stick with common convention due to related user knowledge/expectations--can have severe security implications here that are not always immediately foreseeable: don't break from convention simply to satisfy having seemingly backed yourself into a design corner where something "doesn't look nice" or "doesn't fit": re-examine the surrounding design itself so that it can encompass the conventional interface/component layout. If you have a specific need or reason to change the design related to a functionality change, that would be worth exploring (but will most likely result in the same outcome, per the other answers).

More simply put:

If "everyone" else can fit a login dialog with a password reset link into their login screen, what have you done that makes doing so a difficulty for you? Look to that for something to change first.

"If it ain't broke, don't fix it" simply because something else is broke with it in it. Re-align your thinking as to what the issue is.

Convention at all costs?

Hardly. I'm not arguing that convention can't be wrong. I'm instead saying that an easy first step analysis is to weight convention to a degree where it isn't simply questioned at each corner, short of discovering an issue actually directly relating to the conventional choices and design themselves.

Hopefully the nuance here isn't lost.

It's entirely possible to fully unpack the reason for this, but I find it to be a generally reasonable basic rule that greatly saves on time that nearly always turns out to have been either needlessly wasted or at best poorly spent: don't rush to make changes to something that fits with convention simply because some other choice is in conflict, instead revisit the conflict with the assumption that the convention simply has more weight by default than whatever is on the other side of the conflicting issue.

Often whatever came into conflict with a convention will even turn out to have other shortfalls that simply weren't exposed yet: the fact that accommodating a highly standard convention is problematic in a given design or in conjunction with other design elements is often a warning sign regarding that conflicting design.

On the other hand, when faced with a convention that is causing direct issues (for example, in higher education, it's common to present a "mega menu" despite a complete lack of evidence that this actually helps prospective--or any--students navigate University websites, and one of the most common complaints is often difficulty navigating the website and discovering appropriate content in a meaningful way), then it's worth spending the time to do a proper analysis of what the benefits (and costs) are to changing it, even if ultimately the answer arrived at is still "no".

The key though is that conventional design generally unpacks not only key pre-shared knowledge and user expectations due to global consistency, but it also often represents lessons learned over the course of multiple entities and often years of exposure, some of which may be less immediately obvious and may go deeper than seemingly simple relatively superficial choices. Not always. But often.

Is it possible to chase down each of those reasons? Certainly. But my question is whether it's actually worth the time, especially if doing so turns into a practice you commonly turn to for solving other problems. Personally, the lesson I've learned over years of development and design, is that it's generally a waste of time and ultimately highly unproductive, and more costly than superficial analysis would assume (potentially even in devastating ways when consequences can go beyond simpler satisfaction aspects or reversible user actions), to open things up to changes of conventional choices/elements/layouts simply due to how it fits in with some other choice made, some other design element, etc.

Consider a push-pull door (the classic example, to lean on Norman). What if you want to design the surrounding opening clearance and doorstop area differently, so you change the handle design to allow the door to open an inch further given a design element in the doorstop area that would hit the standard pull handle in a standard vertical orientation, only now it looks like a horizontal push handle instead of a pull? Would spending time considering that have really been worth it, versus simply saying that the doorstop area's creative new design needed to accommodate the conventional design of the door interface? Was whatever new creativeness went into the doorstop area either so important or so entirely constrained to such a high level as to really be worth even exploring that, versus simply exploring an appropriate accommodation in the new design and accepting some degree of related compromise perhaps in that new design?

As a quick example of why it's a good idea to stick with convention particularly in circumstances where mistakes may result in worse implications than simply someone not being pleased with the flow, or the aesthetic (short of a direct functional reason to change from it, with careful exploration of related consequences): what happens if you were to reverse the order of the username and password fields? Let's say it's for a web page: ideally everything is coded correctly so every aspect of this goes across HTTPS as POST fields. What if, in trying to get clever, someone loaded a "reset password" link with the username as a get parameter (querystring)? So what happens when someone tries logging in, puts their credentials in in reverse of the input fields, and then without paying enough attention clicks the "reset password" link... and that happens to be a non https page/endpoint?

Even if it's https, that url with querystring is now in the server logs most likely. Which ideally are secure. And ideally there's no association now with a specific account. But it's one more potential place for that to leak.

What happens if someone tries entering their parameters in reverse during a presentation? This happens even with standard configurations by simple user error (accidental tab/etc), but how often would it happen if the fields were reversed? If there's a malicious actor in the audience, do they get kicked out if they manage to log in during the timeframe between the accidental password reveal and the user resetting their password, or can they keep navigating within the application? etc.

Aside: On Accessibility

(I'm writing this in relation to an assumption of this being in a web page, but similar accessibility concepts/constructs exist in other interfaces)

FYI, this might not be an accessibility issue if this is a webpage that you submit with the submit action being that it loads the same page again from the server with the related markup of a login attempt that did not authenticate alongside a link to the password reset.

Where this becomes a possible accessibility issue is that if this is dynamically AJAXed (single page application/etc), such that it sends the results to the server via client side scripting and then updates the page without reloading it, you may require ARIA tagging (most likely as live regions, and you'll need to carefully consider how much/what you mark as live regions versus not) to allow screen readers to update properly regarding the submission error and the availability of the link.

Particularly with screen readers, it's important to keep in mind that updates to parts of the page that aren't being interacted with can be very non obvious, especially if the person accessing the page has already explored those areas and formed a mental model in relation to them where they no longer anticipate related information being present there. In turn, it requires careful consideration (and actual testing!) to not create a circumstance where dynamic updates create an overwhelming level of immediate feedback via added aria-live decoration (while keeping a flow that allows people to reach related updated information intuitively), and you also need to pay attention to what the dynamic updates do in various screen readers in terms of cursor location changes, if any.

If someone forgets their password they will first look for a forget password so this would just waste the user's time, annoying them causing them to want to leave. Also some people will use the change password to find out a username that they have forgotten so this would force then to try and remember it, annoying them. Finally some users will use the password reset to change the password, this will annoy them as most other sites will do this.

When designing a application/website it is all about making any action easy and fast. Hiding the forgotten password button makes it harder and slower. This should never be done.

As a user, I would be a little upset with your proposal. There are a few sites where I just don't bother to remember the password, and use the "forgot password" feature as a one-time-password system.

If you really need to save space, you could start with a "Forgot password?" button until something is entered in the password field.

In case you are still looking for solutions, how's this.

At the very minimum - the way Google does it - you need an input box for the user name and a "Next" button.

In this case, you can have the button read "Forgot password?" at first, as long as the user hasn't filled in anything in the box. Then as soon as they have input anything, change the button to "Next" to go to the input password screen.

As other members have pointed out, this is primarily a bad idea because it assumes that the user already has a password in mind to try.

If I visit a website I haven't visited in a very long time and the password isn't in my password manager, I'll often simply just reset the password rather than trying to guess what it may be. In such a case, I wouldn't have a password in mind to use on a failed login first.

Secondly, sometimes users will want to reset their password without signing in; for example, in the event of your website being breached. If the link is hidden, this is likely to frustrate users and it may not be immediately obvious how to get the link to show up.

This needs to be answered alongside the context in your question:

we need as much space as possible

I don't know what your login page looks like or why you so desperately need the space, but assuming you do, then yes, an easy thing to cut is a Forgot Password link on the first login page. It's not ideal, and you will probably lose users that come back after a while and don't want to guess a password. You need to balance that and other UX options with your need for real estate.

A more holistic approach to the problem is sharing your current login screen and its detailed space requirements. There are ways to indicate actions to users without a giant text span, and likewise there is probably a better way to solve your problem without hiding functionality.