"Done" but not releasable

Is it correct to assume that feature A in Team A's sprint backlog is already Done?

No. Work must be proven to be Done, which means integrated and ready for immediate release.

• It may be possible to code against common interfaces by means of which Team B's work is stubbed, the feature being turned off until B finishes. When the complete feature is proven to be Done it is flipped on. However, that would mean Team A's work is not conducted in a timely manner, inviting depreciation and waste.
• A better approach would be to self-organize into feature teams, each of which can deliver a feature without dependency. This may require an architecture which supports the modular development and release of features. A and B are then in a position to develop and deliver features under their own steam. This approach effectively descales the challenge.
• If descaling is not possible, and there are only 2 teams, then A and B should be able to co-ordinate between themselves so work is integrated into a feature-complete increment.
• If there are more than 2 teams, they may need to consider a scaling approach such as Nexus, through which they manage their integration dependencies.

Depends. I agree with Ian so let me ask on the proven portion...is there a dependency of Team A Feature A with Team B's feature, for the sake of it being functional/useable? Or is just the production release of Feature A blocked because the release needs to contain Feature B and the two features don't actually interact with each other?

You also said sprint backlog as opposed to product backlog, so within the sprint context if your process can call something done when it's deployed to a staging environment, and it's reviewable, then you can call the stories done. However, I would not call Feature A done from the product backlog until it's actually released. There may still be work to do in the next/current sprint for the integration support. 

This is a great opportunity to set your Definition of Done to match the ideal state and let that light a fire for the needed scalable architecture support. You can capture the cost of delay of your feature and have that help support the operational costs, as opposed to having your DoD consume the accommodation and have external folks believe there is not problem.

Going to pull the opening statements from the Scrum Guide section on the Development Team (emphasis added by me)

The Development Team consists of professionals who do the work of delivering a potentially releasable Increment of "Done" product at the end of each Sprint. A "Done" increment is required at the Sprint Review. Only members of the Development Team create the Increment.

So if your Feature A meets the Definition of Done and everyone agrees that is has, I'd say it can be done.  Is it able to be included in an upcoming release?  Completely different question.  As @Ian Mitchell says the increment has to be proven to be done and ready for immediate release but it doesn't mean it has to be released. 

Both @Ian Mitchell and @John Varela make good points about the dependencies between the two features.  Are they functionally dependent on each other or just releasable dependent on each other? If you are building functional dependent features then you may want to rethink the strategy taking their words into account.  If it is releasable dependencies, welcome to software development but you may want to consider the ability to flip features on and off independently of each other.  That would allow your Feature A to be included in the release but it would just not be available until all of the "checkboxes" for the marketing announcements are complete. 

Thanks for the feedback guys. It seems the next best move is for us to implement scaling, Of course we are eyeing Nexus as the framework to use..