1) that RESUME is a user defined without an associated login (or certificate / key), and

2) that if the login that it thinks it should be associated with isn't defined in the target database then the package will create it with a default password (because we can't get its actual password out of SQL Server).

As long as you know that RESUME is a user without an associated login (i.e. you made it with CREATE USER RESUME WITHOUT LOGIN, or deleted the login it was created for), then you can ignore the first warning. (If you think it should have an associated login, you need to look at your database and reattach the appropriate login with sp_change_users_login, as the message says.)

As long as the login RESUME thinks it should be associated with is in the target database, the second warning should also be harmless. If the user RESUME's login isn't in the target database, the package will create the user and may also create a login called RESUME with the password 'p@ssw0rd' which you'll have to change manually afterwards.

(The package will create a login if the original user was once bound to a login - it shouldn't create any logins if the original user has always been without a login, i.e. it was defined WITHOUT LOGIN rather than being defined for a login which has since disappeared.)

I am reviewing your software and unclear on the next steps I should take to clear this up with. I need for the database that I am testing with a user name RESUME with password RESUME for this test. The databases name is Resume.

I'm slightly unclear on what your requirements are. I think what you are saying is that you need to end up with:

1) A login called RESUME with password RESUME on the target server
2) A user called RESUME linked to this login

And you are starting with:
1) A user called RESUME which used to be linked to a login called RESUME but has become unlinked, in the source database

There are two ways you can achieve what you want, although neither are particularly optimal:
1) Ensure there is a login called RESUME with password RESUME on the target server before you run the package
2) After you run the package, change the password of the newly created login called RESUME to RESUME - you can do this with the /postsql command line option added in v5.2, which allows you to add a SQL file to run after package deployment to the package.

/postsql is a bit undocumented (it was added quickly as a feature in a point release, and we haven't rewritten the documentation properly since then) so please ask more questions if you get stuck using it.

So is it not possible to create a good set up of the RESUME login on the source server/DB and then package it with your software and have it run through cleanly? If you would outline what needs to happen on the source server/db that would resolve the setup process via your packager, that would be what we need from your software.