Cookies are domain-dependent. You don't decide, from the server side, which cookie you read; the browser sends the stored cookies that match the name (with domain) of the target server.
If you want to share some authentication in some SSO manner, then you need both servers A and B to delegate the authentication to a common third server C. That server will do the login+password dialog, and store a cookie in the browser. Neither A nor B will ever see that cookie. Instead, they communicate directly with server C to know who is at the other end of the line. This is how OpenID works. Incidentally, that is what is used to authenticate with StackExchange sites: when they say "log in with Facebook", this means that a Facebook server will do the authentication, and the StackExchange servers won't see the password or any Facebook cookie.
Another method is to put up a front-end site D that you control, and does the authentication, and forwards all requests and responses to site A or site B, rewriting all URL within the HTML to maintain its position as a middle-man. Some vendors offer appliances that do that job (e.g. NetIQ, but they are not the only one on that market). Of course, this means that from the point of view of the end user, all the contents is served by site D, not A or B; the owner of B might sue you for unauthorized reproduction or plagiarism (whether they would win is another question).