Is this login security enough?

The key factors I always look for in a Project Definition spec are missing here:

What are you protecting? Who are you protecting it from? What is the impact if it is compromised?

If you are protecting your list of friends birthdays it is almost certainly overkill. If you are protecting Top Secret material from International or Corporate espionage then it may well be too weak.

You need to think about the potential risk, the threat actors who may target you, and other factors such as resiliency (does a failed login on a Monday morning make it exceedingly difficult for a user to gain access when they really need to)

Hopefully you do have answers to these, but unless you post them here it can be hard for others to provide guidance on security architecture.

Beware of overkill, it is counterproductive. If your login system is too inconvenient or annoying, users will actively try to work around it. "Users", here, includes application developers and server administrators.

login form is SSL secured

This one is the most important, but not "alone". Theoretically, the whole site should be secured with SSL, not just the login form. SSL provides confidentiality with regards to eavesdroppers, but if it results in a cookie which you afterwards send in the clear to maintain the session, then an eavesdropper just have to send the same cookie to hijack a session. If only the login form is SSL-protected, the only security you get here is in combination with a thorough anti-phishing training: you educate the users into refraining from sending their password to sites which do not have SSL active, and therefore you need a SSL site yourself. But that's marginal.

password is converted to sha256 before being transmitted (bcrypt is too slow still for JS/ browser client)

This one is useless. It just means that the SHA-256 result is the password. If it can be grabbed by an attacker, then the attacker can use it to log in, without even knowing the "true" password.

hashed password is encrypted with private key stored as CONSTANT in app/file

This feature is a security gain only in the situation where the attacker could get the hashed passwords but not the application files themselves. Whether this is a realistic situation is debatable. On the other hand, that constant key will annoy administrators when the application is to be updated, and may incur extra downtime (it is so easy to forget it when deploying...). Also, this makes confidentiality of the application files an important goal, which is rather uncommon.

recaptcha upon 1st login failure

This will be more annoying than secure.

login strike system per device, so if the user tries 5 diff logins and theyre all wrong, he's out. its not 5 per login

Don't block accounts, just add delays (e.g. one minute). Otherwise, anybody can lock the account of anybody, which is a problem. Counting tries per device is good, but is subtle, and can backfire: there are some networks (including ISP) out there with massive NAT or proxying, which turn into, from the server point of view, thousands of login requests from the same source IP.

2step auth using sms, email? or AlterEgo - maybe once per device + location and to be used if you want to change your password

if logging in from a different location different from history, send SMS/Email to user

SMS may annoy users: they do not work well for international users, they require a functional mobile phone on the spot, and some people are charged for the SMS they receive (it depends on the country and mobile phone provider). Email is marginally better (but, of course, not if the application you are trying to protect is a webmail...).

have option to save login device+location in history (ie dont use this option if your at a netcafe or a public network etc) so it will always ask for your 2step

Note that in a netcafe, security goes down the sink. A key logger is just too invisible. There is not much you can do against that.

So think I'm going overkill?

Yes. But, more importantly, you also lack the important feature, which is site-wide SSL.

You're using lots of security buzzwords here - but the end result is not as secure as should be, and as Lucanos says there's a lot of redundancy.

Go read this thread.

password is converted to sha256 before being transmitted (bcrypt is too slow still for JS/ browser client) bcrypt stored hashes

Does that mean you generate a bcrypt hash of the sha256 hash of the password? Without a salt the sha256 password does nothing to help the security, and using a second round of hashing doesn't help either.

hashed password is encrypted with private key stored as CONSTANT in app/file

What? Why? Do you ever want to recover the hash of the hash of the password? Even if you did, the way to do this would be to encrypt using a public key.

recaptcha upon 1st login failure

Doesn't add a lot of value.

if device/location information changes while logged in, kill session

So we're talking about session management as well as authentication - in that case you've still got lot of work to do.